Re: [v6ops] Please review the No IPv4 draft

[Ray Hunter <[e-mail]>]

> Ted Lemon <mailto:[e-mail]>
> 17 April 2014 16:43
>
> In an enterprise network, if you aren't filtering rogue RAs, you 
> probably need to hire a new network administrator. But yeah, that's 
> definitely an issue that should be covered in the security 
> considerations section.
>
Lorenzo said it already: the impact is potentially much more serious.

If you've left IPv6 enabled on end nodes, but given IPv4 absolute 
priority in the permanent copy of the RFC6724 address selection rules 
table, any IPv6 addressing and routing would only become active when 
connected to an IPv6 only environment. If you've not (correctly) taken 
heed of RFC6104 (and a lot of people haven't), any rogue RA would 
probably only be a temporary annoyance to IPv4 which anyway goes away 
automatically with the rogue RA. Same is true for nodes implementing 
Happy Eyeballs RFC6555.

If you had a complete protocol shutdown due to 
draft-ietf-sunset4-noipv4-00 (assuming the proposed flag is carried in a 
rogue RA) you may need a helpdesk call, a site visit, or access to an 
out of band console to be able to restart your machines.

How would most mere mortals find a rogue RA (process) that only sends a 
handful of packets per week/month and where the purpose of the packet is 
obfuscated with headers? RFC7113 was only published in February 2014.

Potential Ping of Death all over again.
> Ray Hunter <mailto:[e-mail]>
> 17 April 2014 10:55
>
>
> Mikael Abrahamsson wrote:
>> On Wed, 16 Apr 2014, Dale W. Carder wrote:
>>
>>> So, I am not in favor of adding more hints that may or may not 
>>> observed that result in additional complexity and create an even 
>>> more diverse set of behavior that has to be managed.  This is why I 
>>> think the only real solution that would work in practice is 
>>> ethertype filtering.
> +1
>>
>> That still doesn't solve the problem of the enterprise network being 
>> IPv6 only but publishes A and AAAA entries for internal resources on 
>> the internal DNS zone, because other networks they have are dual stack.
>>
>> Otoh I think this would be better solved by implementing MIF 
>> functionality in the device but... oh well.
>>
> Enterprise networks will use alternative protocols/methods to 
> configure their end nodes IMHO e.g. Active Directory
>
> And we have https://tools.ietf.org/html/rfc7078 for cases where some 
> LANs are IPv4 only, some are dual stack, and others are IPv6 only 
> (assuming anyone implements it)
>
> I'm hoping that a node connected to an authenticated AD server will by 
> default ignore any unauthenticated configuration hints purportedly 
> sent via a DHCPv6 server.
>
> Although as I've pointed out earlier, there could be serious race 
> conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives 
> before AD authentication).
>
> ------------------------------------------------------------------------


-- 
Regards,
RayH