Issue title: Ipvs: NodePort entries for localhost (116.69.203.115, 38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5) are created but can't be used
 Issue body: **What happened**:

For services with type NodePort (and LoadBalancer) ipvs entries for localhost (ipv4 and ipv6) are created. Here is an example for a service with `ipFamilyPolicy: PreferDualStack` so the same nodeport is used for ipv4 and ipv6;

```
$ ipvsadm -Ln | grep 31201
TCP  116.69.203.115:31201 rr
TCP  116.69.203.115:31201 rr
TCP  116.69.203.115:31201 rr
TCP  116.69.203.115:31201 rr
TCP  [38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5]:31201 rr
TCP  [38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba51:c0a8:2]:31201 rr
TCP  [38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba51:c0a8:102]:31201 rr
TCP  [38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5201]:31201 rr
$ curl -s -D - http://116.69.203.115:31201 | grep -F "200 OK"
HTTP/1.1 200 OK
$ curl -s -D - http://116.69.203.115:31201
(hangs)
$ curl -s -D - http://[38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba51:c0a8:102]:31201 | grep -F "200 OK"
HTTP/1.1 200 OK
$ curl -s -D - http://[38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5]:31201
(hangs)
```

The localhost entries can't be used and most likely they never will.


**What you expected to happen**:

Since "38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5" most likely will never work and 116.69.203.115 will not work without an unlikely Linux kernel update these entries must not be created.

Further, since the use of localhost addresses for nodeports is the only know reason to require `net.ipv4.conf.all.route_localnet=1` (#90259), this requirement shall be removed for proxy-mode=ipvs.


**How to reproduce it (as minimally and precisely as possible)**:

* Start a cluster with proxy-mode=ipvs and some services
* Do; `ipvsadm -Ln | grep 116.69.203.115`


**Anything else we need to know?**:

That ipv6 access to [38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5]:nodeport does not work (and most likely never will) is discussed in https://github.com/kubernetes/kubernetes/issues/90236.

For 116.69.203.115 is is a bit more complicated as discussed in https://github.com/kubernetes/kubernetes/issues/67730, with the excellent deep-dive into the kernel by @chendotjs in https://github.com/kubernetes/kubernetes/issues/67730#issuecomment-578859752.

This may seem like a minor issue but clean-up of useless things is always good. I also have (vague) plans to propose improvements for the address handling for proxy-mode=ipvs and the localhost entries becomes an unwanted problem.

If this issue is accepted as a bug I'll be happy to do a PR.

**Environment**:

- Kubernetes version (use `kubectl version`): all supporting proxy-mode=ipvs
- Cloud provider or hardware configuration: any
- OS (e.g: `cat /etc/os-release`): any
- Kernel (e.g. `uname -a`): any
- Install tools: none
- Network plugin and version (if this is a network-related bug): any
- Others:

/kind cleanup
/sig network
/area ipvs

 Comments: 
 Comment 0: @uablrek: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the `triage/accepted` label and provide further guidance.

The `triage/accepted` label can be added by org members by writing `/triage accepted` in a comment.


<details>

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
</details>
 Comment 1: test in ipv6 + iptables , 38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 is not work for NodePort. 

/assign 

 Comment 2: Issues go stale after 90d of inactivity.
Mark the issue as fresh with `/remove-lifecycle stale`.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with `/close`.

Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community).
/lifecycle stale
 Comment 3: /area kube-proxy
 Comment 4: /remove lifecycle-stale

 Comment 5: /remove-lifecycle stale

<sigh...>
 Comment 6: Since it is highly unlikely that the kernel will be updated to allow this for ipv4 and it will never work for ipv6 I would *really* want to remove this from the ipvs proxier.



 Comment 7: @aojea @thockin Do you think I can go ahead and disable the setup for localhost node-ports in the ipvs proxier?

Since it have never worked it would not be a user facing change.

Or should we discuss it on the sig/network meeting?
 Comment 8: I personally think that this was implicitly discussed and confirmed here https://github.com/kubernetes/kubernetes/pull/92938 , it is an implementation detail of IPVS and a known issue that never worked in IPVS, so it will be safe to disable directly without further discussion.
However, I defer to @thockin for a final decision
/assign @thockin 
 Comment 9: I made a PR. It's just 3 lines :smile: 
{'source': 'GithubIssues', 'repo_name_with_owner': 'kubernetes/kubernetes', 'issue_id': 751369336, 'repo_stars': 93454.0}