text: Title: kube-proxy: ipv4/ipv6 mix crashes: KUBE-MARK-DROP':No such file or directory
  Body: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!-->
  
  Hi there,
  
  I'm not entirely sure if this is a bug or a funny configuration fault. Since that exact configuration worked before, I'm still reporting it.
  
  **What happened**:
  
  Having mixed IPv4 and IPv6 addresses for pods prevented `kube-proxy` (in `iptables` mode) from creating iptables rules. Logged was an error from iptables-save: `Couldn't load target 'KUBE-MARK-DROP':No such file or directory`.
  
  Since there weren't a lot iptables rules written before the crashing command, network was completely down on that node.
  
  This problem only affected a single node of my 4 node cluster (3 controllers which are also workers, one additional worker). Affected node was a controller node.
  
  **What you expected to happen**:
  
  Create iptables rules as the cluster did before I started with the upgrades.
  
  **How to reproduce it (as minimally and precisely as possible)**:
  
  I started today with upgrading my cluster from 1.10.11 to 1.13.2 (installing every latest patch version for every minor in order). This problem started shortly after rolling out 1.12.5 after a node had an unrelated problem and had to be restarted. I think that reboot only uncovered the bug and the other nodes would also be affected after a reboot (or `kube-proxy --cleanup`).
  
  I had a funny-but-working config. My containers all have IPv4 addresses, but kubelet was configured to use the IPv6 address of the node (`--node-ip`, `--address`). This resulted in Pods created by a DaemonSet having IPv6 addresses.
  
  That exact configuration worked on 1.10.11 and broke somewhere newer. The versions installed today before seeing the bug were 1.10.12, 1.11.7 and 1.12.5. 
  
  Fixing the kubelet config to use the IPv4 node address in the flags given above, restarting all kubelets and kube-proxies and then deleting all pods created by DaemonSets fixed the issue.
  
  
  **Anything else we need to know?**:
  
  **Environment**: 
  - Kubernetes version (use `kubectl version`): stated above
  - Cloud provider or hardware configuration: virtual machines, different specs
  - OS (e.g. from /etc/os-release): Debian Stretch (current stable)
  - Kernel (e.g. `uname -a`): 4.9.0-8-amd64 (debian stretch kernel)
  - Install tools: custom playbooks for Ansible, can be provided with history regarding this bug
  - Others: no CNI plugin but static routes
  