Re: How is IPv6 dhcp supposed to work?

From: Dan Williams <dcbw@redhat.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: Ben Greear <greearb@candelatech.com>, netdev <netdev@vger.kernel.org>
Subject: Re: How is IPv6 dhcp supposed to work?
Date: Wed, 18 Jun 2014 08:43:10 -0500	[thread overview]
Message-ID: <1403098990.2266.13.camel@dcbw.local> (raw)
In-Reply-To: <87ha3isdu6.fsf@nemi.mork.no>

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