Re: [v6ops] Please review the No IPv4 draft

[Nick Hilliard <[e-mail]>]

On 29/04/2014 17:08, Ted Lemon wrote:
> It also doesn't establish it.   That was what I was asking for earlier.
> I think that if there is a serious gap here, the working group should
> consider that.   But we haven't actually established that such a gap
> exists.   My intuition is that you may be right about this, but I'd like
> to go on more than intuition.

there are three issues here: 1. how much kit out there that doesn't support
ra guard / dhcpv6 snooping or basic ipv6 acls on l2 ports, 2. for the kit
that does support these features, how good is that support and 3. how
important this is to the noipv4 proposal.

#1 is highly platform specific and depends on both hardware and software
support. e.g. Cisco Nexus 3000 doesn't support ipv6 acls on L2 ports.
cisco nexus 1000v doesn't support ipv6 acls at all.  Cisco 6500 boxes
support ra guard but not dhcpv6 guard.  Brocade ironware boxes will support
IPv6 ACLs, but can only install them on L2 ports on certain platforms, and
even then only if you don't have mac filters installed on those ports.
Same mac||ip filter problem on netiron s/w.

#2 is complicated enough that Fernando Gont wrote an ID on the topic.  Many
platforms are subject to the sort of fragmentation / extension header
evasion techniques that Fernando describes.  The only switch which I've
heard to support ra guard for difficult packets is the windows hyperv
soft-switch.  Hardware forwarded switches seem to be particularly prone to
the problem

#3: the ietf is fully within remit to write this off as an operational
issue and not a protocol problem, and that if your ipv6 first hop security
mechanism is broken, then you have bigger problems.  While this is
undoubtedly true, the draft will create the requirement for all networks -
including legacy ones - to protect against rogue RA / DHCPv6 packets
because otherwise you could find that newer clients on unprotected legacy
networks would be susceptible to having their ipv4 stacks shut down if
someone with a sense of humour starts playing around.

#3 means that the network operator must be trusted.  I don't trust many of
the networks that I connect to because sometimes operators and other agents
are malicious and I expect my phone / laptop / etc not to be particularly
interfered with by their malice.  The level of policy interference from
this ID is very large indeed.

Nick