netdev - Re: How is IPv6 dhcp supposed to work?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1403098990.2266.13.camel@dcbw.local>
Date:	Wed, 18 Jun 2014 08:43:10 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Ben Greear <greearb@...delatech.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: How is IPv6 dhcp supposed to work?

On Wed, 2014-06-18 at 12:37 +0200, Bjørn Mork wrote:
> Ben Greear <greearb@...delatech.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@...ech2-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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html