Skip to contentSkip to conversation

How is IPv6 dhcp supposed to work?

DISCUSSION Ben Greear 6 participants 10 messages Jun 17, 2014 – Jul 1, 2014

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

I'm trying to understand how DHCP for ipv6 is supposed to work.

I am able to get a global-scope address and prefix from dhclient, but dhclient is not providing a gateway address.

I see the dhclient interface doing a Router Solicitation, but I don't see any answers.

Are we supposed to run radvd or something like that as well?

Or is there some other automated magic that is supposed to find the default gateway?

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#1 lore raw
Quoted 4 lines · Ben Greear

I'm trying to understand how DHCP for ipv6 is supposed to work.

I am able to get a global-scope address and prefix from dhclient, but dhclient is not providing a gateway address.

That's because it doesn't; DHCPv6 isn't supposed to be used standalone for global IPv6 connectivity. That's what router advertisements are for. The normal flow is this:

1) your router advertisement provides your prefix, prefix length (eg subnet mask), and default gateway/router

2) your prefix gets combined with your local Interface Identifier (often your MAC address or a hashed version of your MAC, or delivered via PPP, or hashed InfiniBand port GUID, or GRE tunnel address, etc) to provide your global IPv6 address. See net/ipv6/addrconf.c::ipv6_generate_eui64().

3) the RA can also provide search domains, DNS servers, routes, MTU, etc.

4) if there's anything else your administrator really wants to use DHCP for (NTP servers, etc) then they set the M (Managed) or O (Other Config) bits in the router advertisement.

5) In both cases, that requests that the client run DHCPv6; in M mode you do get a lease from the DHCP server and that address becomes preferred, in the O case no lease is obtained but other options can be delivered

6) In all cases, the default gateways (and their respective priorities) are always delivered by Router Advertisements; there can be multiple default gateways in the broadcast domain for redundancy, and the network administrator sets their relative priority.

Quoted 4 lines

I see the dhclient interface doing a Router Solicitation, but I don't see any answers.

Are we supposed to run radvd or something like that as well?

Yes. If you're not using static addressing, then you must run radvd to deliver router advertisements to your network. See 'man radvd.conf' for more information on configuring the additional options that DHCP used to be used for (RDNSS, DNSSL, AdvLinkMTU, route, etc).

Quoted 2 lines

Or is there some other automated magic that is supposed to find the default gateway?

Router Advertisements via radvd. You probably want to evaluate whether you really need DHCPv6 at all, since RA can deliver most of the options that people use DHCP for.

Dan

author
#2 lore raw
Quoted 46 lines · Dan Williams
Quoted 4 lines · Ben Greear

I'm trying to understand how DHCP for ipv6 is supposed to work.

I am able to get a global-scope address and prefix from dhclient, but dhclient is not providing a gateway address.

That's because it doesn't; DHCPv6 isn't supposed to be used standalone for global IPv6 connectivity. That's what router advertisements are for. The normal flow is this:

1) your router advertisement provides your prefix, prefix length (eg subnet mask), and default gateway/router

2) your prefix gets combined with your local Interface Identifier (often your MAC address or a hashed version of your MAC, or delivered via PPP, or hashed InfiniBand port GUID, or GRE tunnel address, etc) to provide your global IPv6 address. See net/ipv6/addrconf.c::ipv6_generate_eui64().

3) the RA can also provide search domains, DNS servers, routes, MTU, etc.

4) if there's anything else your administrator really wants to use DHCP for (NTP servers, etc) then they set the M (Managed) or O (Other Config) bits in the router advertisement.

5) In both cases, that requests that the client run DHCPv6; in M mode you do get a lease from the DHCP server and that address becomes preferred, in the O case no lease is obtained but other options can be delivered

6) In all cases, the default gateways (and their respective priorities) are always delivered by Router Advertisements; there can be multiple default gateways in the broadcast domain for redundancy, and the network administrator sets their relative priority.

Quoted 4 lines

I see the dhclient interface doing a Router Solicitation, but I don't see any answers.

Are we supposed to run radvd or something like that as well?

Yes. If you're not using static addressing, then you must run radvd to deliver router advertisements to your network. See 'man radvd.conf' for more information on configuring the additional options that DHCP used to be used for (RDNSS, DNSSL, AdvLinkMTU, route, etc).

Quoted 6 lines
Quoted 2 lines

Or is there some other automated magic that is supposed to find the default gateway?

Router Advertisements via radvd. You probably want to evaluate whether you really need DHCPv6 at all, since RA can deliver most of the options that people use DHCP for.

Thanks for the detailed answer. A user told me that 'dhcpv6 didn't work'.

And it doesn't, but I think maybe they were using the equivalent of radvd anyway....trying to verify that.

Now, I still have troubles though. I see the router solicit, and router advertisement, but 'ip monitor route' doesn't show any default route being added (and neither does the route show up in some other way I know to look.)

I'm using routing rules, veth pairs, and such stuff, and have some local code hacks, so maybe it's my fault. Don't think I've mucked with IPv6 much though...

Does that router advert below look proper? I'm going printk diving in the IPv6 stack in the meantime...

[root@simech2-f17x64 lanforge]# cat pkt.txt
No. Time Source Destination Protocol Length Info

     34 229.636063  fe80::e4be:86ff:fe27:a33 ff02::1               ICMPv6   110    Router Advertisement from e6:be:86:27:0a:33

Frame 34: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Ethernet II, Src: e6:be:86:27:0a:33 (e6:be:86:27:0a:33), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) Internet Protocol Version 6, Src: fe80::e4be:86ff:fe27:a33 (fe80::e4be:86ff:fe27:a33), Dst: ff02::1 (ff02::1) Internet Control Message Protocol v6

    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x6088 [correct]
    Cur hop limit: 64
    Flags: 0x00
    Router lifetime (s): 300
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2001:78::1/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xe0
        Valid Lifetime: 86400
        Preferred Lifetime: 14400
        Reserved
        Prefix: 2001:78::1 (2001:78::1)
    ICMPv6 Option (Source link-layer address : e6:be:86:27:0a:33)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: e6:be:86:27:0a:33 (e6:be:86:27:0a:33)

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#3 lore raw
Quoted 59 lines · Ben Greear
Quoted 46 lines · Dan Williams
Quoted 4 lines · Ben Greear

I'm trying to understand how DHCP for ipv6 is supposed to work.

I am able to get a global-scope address and prefix from dhclient, but dhclient is not providing a gateway address.

That's because it doesn't; DHCPv6 isn't supposed to be used standalone for global IPv6 connectivity. That's what router advertisements are for. The normal flow is this:

1) your router advertisement provides your prefix, prefix length (eg subnet mask), and default gateway/router

2) your prefix gets combined with your local Interface Identifier (often your MAC address or a hashed version of your MAC, or delivered via PPP, or hashed InfiniBand port GUID, or GRE tunnel address, etc) to provide your global IPv6 address. See net/ipv6/addrconf.c::ipv6_generate_eui64().

3) the RA can also provide search domains, DNS servers, routes, MTU, etc.

4) if there's anything else your administrator really wants to use DHCP for (NTP servers, etc) then they set the M (Managed) or O (Other Config) bits in the router advertisement.

5) In both cases, that requests that the client run DHCPv6; in M mode you do get a lease from the DHCP server and that address becomes preferred, in the O case no lease is obtained but other options can be delivered

6) In all cases, the default gateways (and their respective priorities) are always delivered by Router Advertisements; there can be multiple default gateways in the broadcast domain for redundancy, and the network administrator sets their relative priority.

Quoted 4 lines

I see the dhclient interface doing a Router Solicitation, but I don't see any answers.

Are we supposed to run radvd or something like that as well?

Yes. If you're not using static addressing, then you must run radvd to deliver router advertisements to your network. See 'man radvd.conf' for more information on configuring the additional options that DHCP used to be used for (RDNSS, DNSSL, AdvLinkMTU, route, etc).

Quoted 6 lines
Quoted 2 lines

Or is there some other automated magic that is supposed to find the default gateway?

Router Advertisements via radvd. You probably want to evaluate whether you really need DHCPv6 at all, since RA can deliver most of the options that people use DHCP for.

Thanks for the detailed answer. A user told me that 'dhcpv6 didn't work'.

And it doesn't, but I think maybe they were using the equivalent of radvd anyway....trying to verify that.

Quoted 6 lines

Now, I still have troubles though. I see the router solicit, and router advertisement, but 'ip monitor route' doesn't show any default route being added (and neither does the route show up in some other way I know to look.)

I'm using routing rules, veth pairs, and such stuff, and have some local code hacks, so maybe it's my fault. Don't think I've mucked with IPv6 much though...

Naive question, what is the value of accept_ra?
cat /proc/sys/net/ipv6/conf/*/accept_ra

See Documentation/networking/ip-sysctl.txt

#4 lore raw
In reply to Ben Greear
Quoted 1 line · Ben Greear

Does that router advert below look proper?

No, it doesn't. How did you create this?

Quoted 21 lines

I'm going printk diving in
the IPv6 stack in the meantime...

[root@simech2-f17x64 lanforge]# cat pkt.txt
No. Time Source Destination Protocol Length Info

     34 229.636063  fe80::e4be:86ff:fe27:a33 ff02::1               ICMPv6   110    Router Advertisement from e6:be:86:27:0a:33

Frame 34: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Ethernet II, Src: e6:be:86:27:0a:33 (e6:be:86:27:0a:33), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) Internet Protocol Version 6, Src: fe80::e4be:86ff:fe27:a33 (fe80::e4be:86ff:fe27:a33), Dst: ff02::1 (ff02::1) Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x6088 [correct]
Cur hop limit: 64
Flags: 0x00
Router lifetime (s): 300
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2001:78::1/64)

Quoted 8 lines

Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xe0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: 2001:78::1 (2001:78::1)

Quoting RFC 4861 (http://tools.ietf.org/html/rfc4861#section-4.6.2 ):

Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.

So that prefix should have been '2001:78::'

Note that you don't necessarily need to include a prefix option in the RA. If you don't want clients on the link connected to the router to communicate directly on L2. This is the typical ISP use case.

Bjørn

#6 lore raw
In reply to Bjørn Mork
Quoted 46 lines · Bjørn Mork
Quoted 1 line · Ben Greear

Does that router advert below look proper?

No, it doesn't. How did you create this?

Quoted 21 lines

I'm going printk diving in
the IPv6 stack in the meantime...

[root@simech2-f17x64 lanforge]# cat pkt.txt
No. Time Source Destination Protocol Length Info

     34 229.636063  fe80::e4be:86ff:fe27:a33 ff02::1               ICMPv6   110    Router Advertisement from e6:be:86:27:0a:33

Frame 34: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Ethernet II, Src: e6:be:86:27:0a:33 (e6:be:86:27:0a:33), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) Internet Protocol Version 6, Src: fe80::e4be:86ff:fe27:a33 (fe80::e4be:86ff:fe27:a33), Dst: ff02::1 (ff02::1) Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x6088 [correct]
Cur hop limit: 64
Flags: 0x00
Router lifetime (s): 300
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2001:78::1/64)

Quoted 8 lines

Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xe0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: 2001:78::1 (2001:78::1)

Quoting RFC 4861 (http://tools.ietf.org/html/rfc4861#section-4.6.2 ):

Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.

Quoted 1 line

So that prefix should have been '2001:78::'

This is actually a problem in the wild, and radvd doesn't prevent this being configured (thanks radvd!!!). So client implementations do need to mask off any host bits in the received prefix, no matter what the RFC says :(

Dan

author
#7 lore raw

After more printk debugging, it seems it is failing to accept the RA due to ipv6_chk_addr failing in the ndisc_router_discovery method.

This is probably because one interface on my system is running radvd (on one side of a veth pair), and the peer veth is supposed to be accepting the ra.

The chk_addr is checking if the source addr for the RA is not found locally, as far as I can tell, but in my case, it is local, and it still should be accepted.

My case is a bit special (I'm doing virtual network type things), but maybe there is a more useful reason to allow this restriction to be relaxed with yet another sysctl?

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#8 lore raw
Quoted 7 lines · Ben Greear

After more printk debugging, it seems it is failing to accept the RA due to ipv6_chk_addr failing in the ndisc_router_discovery method.

This is probably because one interface on my system is running radvd (on one side of a veth pair), and the peer veth is supposed to be accepting the ra.

Quoted 6 lines

The chk_addr is checking if the source addr for the RA is not found locally, as far as I can tell, but in my case, it is local, and it still should be accepted.

My case is a bit special (I'm doing virtual network type things), but maybe there is a more useful reason to allow this restriction to be relaxed with yet another sysctl?

This is probably long solved by now, but network namespaces solve this problem very simply. What is local in one network namespace is not considered local in another.

Eric

author
#9 lore raw
In reply to Bjørn Mork
Quoted 5 lines · Bjørn Mork
Quoted 1 line · Ben Greear

Does that router advert below look proper?

No, it doesn't. How did you create this?

With a radvd config with this section in it:

interface rddVR2
{
AdvSendAdvert on;
IgnoreIfMissing on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2001:78::1/64

   {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;

};
route ::/0 {
};
};

I'll try changing it to zero out the low 64-bits....

Quoted 10 lines · Quoting RFC 4861 (http://tools.ietf.org/html/rfc4861#section-4.6.2 ):

Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.

Quoted 5 lines

So that prefix should have been '2001:78::'

Note that you don't necessarily need to include a prefix option in the RA. If you don't want clients on the link connected to the router to communicate directly on L2. This is the typical ISP use case.

I just want the 'rddVR2' interface to effectively give out it's own IPv6 addr as the default IPv6 gateway for anything connected to rddVR2, and I want the 'rddVR3' interface (this is a veth pair, by the way) to use that IPv6 addr as it's gateway.

To answer another question in this thread: Yes, accept_ra is 1, and I checked the other pertinent procfs values and they are correct for my desired behaviour as far as I can tell.

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com