<p dir="ltr"><br>
On 14 Jul 2015 6:45 pm, "Peter Fern" <<a href="mailto:ausnog@0xc0dedbad.com">ausnog@0xc0dedbad.com</a>> wrote:<br>
><br>
> On 07/14/2015 18:22, Mark Smith wrote:<br>
> > So I think Lorenzo's objection is specifically about stateful address<br>
> > assignment via DHCPv6 because it doesn't actually solve the problem<br>
> > people think it does - to have a database of attached devices for<br>
> > security purposes. DHCPv6 or DHCPv4 won't have a record of attackers<br>
> > devices that are configured with static addresses. In the case of<br>
> > IPv6, DHCPv6 won't have a record of hosts' link-local addresses<br>
> > either. An attacker will have control of their machine, so they'll<br>
> > very easily ignore the M flag in RAs (indicating to use DHCPv6 for<br>
> > addresses), or more simply, sniff but not process RAs, so they know<br>
> > the network's subnets and can configure a static address and static<br>
> > default gateway if necessary.<br>
><br>
> Sure, I get this - if that's the only reason people think they want to<br>
> deploy IPv6, then they're doing it wrong(tm).  But this is not the only<br>
> reason to choose DHCPv6 as your addressing mechanism - stuff like<br>
> options support so that you can push TFTP etc, central address<br>
> management, GSS-TSIG, whatever.</p>
<p dir="ltr">Actually, I strongly agree with using DHCPv6 for these purposes, meaning stateless DHCPv6 (i.e. don't use it for addresses), to the point where I wrote an IETF Internet Draft on it relating to CPE:</p>
<p dir="ltr">IPv6 CE Device DHCPv6 Option Transparency<br>
<a href="https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00">https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00</a><br><br></p>
<p dir="ltr">  The point is that people are free to<br>
> choose the mechanism that they've decided is right for their network,<br>
> whatever their reasoning.<br>
><br>
> > If you truly want a database of attached devices, you need to be<br>
> > recording IPv6 neighbor cache contents, IPv4 ARP cache contents or<br>
> > later two FDB contents. Then, in the case of IPv6, the address<br>
> > configuration method (static, SLAAC, DHCPv6) doesn't matter.<br>
> ><br>
> > And if your truly want to control and record both the identities of<br>
> > the devices and the *people* behind then (which includes potential<br>
> > attackers), you authenticate them at layer 2, using e.g. 802.1X.<br>
> ><br>
><br>
> Absolutely.<br>
><br>
> > BTW, I think Lorenzo is being rational. Being "religious" is objecting<br>
> > to something different just because it is different.<br>
> ><br>
><br>
> Except that Lorenzo really can't dictate how operators are going to<br>
> configure their networks, so declaring that if operators implement<br>
> addressing in a manner that conflicts with Lorenzo's opinion on how it<br>
> should be done - irrespective of the RFCs - users of the Android<br>
> operating system will be refused IPv6 connectivity, really does not<br>
> strike me as a rational stance, and would seem to satisfy your<br>
> definition of "religious" ;-)<br>
</p>