How is IPv6 dhcp supposed to work?

How is IPv6 dhcp supposed to work?

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

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How is IPv6 dhcp supposed to work?

[Dan Williams]

On Tue, 2014-06-17 at 14:41 -0700, Ben Greear wrote:
> 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.

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

> 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

Re: How is IPv6 dhcp supposed to work?

[Ben Greear]

On 06/17/2014 03:34 PM, Dan Williams wrote:
> On Tue, 2014-06-17 at 14:41 -0700, Ben Greear wrote:
>> 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.
> 
>> 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).
> 
>> 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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How is IPv6 dhcp supposed to work?

[Nicolas Dichtel]

Le 18/06/2014 01:16, Ben Greear a écrit :
> On 06/17/2014 03:34 PM, Dan Williams wrote:
>> On Tue, 2014-06-17 at 14:41 -0700, Ben Greear wrote:
>>> 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.
>>
>>> 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).
>>
>>> 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...
Naive question, what is the value of accept_ra?
cat /proc/sys/net/ipv6/conf/*/accept_ra

See Documentation/networking/ip-sysctl.txt

Re: How is IPv6 dhcp supposed to work?

[Bjørn Mork]

Ben Greear <greearb@candelatech.com> writes:

> Does that router advert below look proper? 

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

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

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

Re: How is IPv6 dhcp supposed to work?

[Hagen Paul Pfeifer]

Strange, exactly today a updated ID was released, titled:
"DHCPv6/SLAAC Address Configuration Interaction Problem Statement"
[1]. To quote the conclusion: "The host behavior of SLAAC/DHCPv6
interaction is ambiguous in standard". ;-)

Cheers, Hagen

[1] http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-01

Re: How is IPv6 dhcp supposed to work?

[Dan Williams]

On Wed, 2014-06-18 at 12:37 +0200, Bjørn Mork wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
> > Does that router advert below look proper? 
> 
> No, it doesn't.  How did you create this?
> 
> > 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)
> 
> 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::'

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

Re: How is IPv6 dhcp supposed to work?

[Ben Greear]

On 06/18/2014 03:37 AM, Bjørn Mork wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
>> 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....


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

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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How is IPv6 dhcp supposed to work?

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

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: How is IPv6 dhcp supposed to work?

[Eric W. Biederman]

Ben Greear <greearb@candelatech.com> writes:

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

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