Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    > That is, I think, irrelevant. All we are really talking about is the order in which results are returned by getaddrinfo(), which is what RFC6724 determines. At present, you will get this back from getaddrinfo() for a locally defined DNS entry (in Pythonic format):

    > (<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))
    > (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fdee:face:fade::a', 0, 0, 0))

What if the values returned are:
   192.0.0.1
   fdee:face:fade::a

That is, a public IPv4, and a ULA?

An enterprise that would prefer to keep certain traffic inside the firewall
(the ULA), but which also wants to provide external access for those working
remote might do this.  But said Enterprise does not have external IPv6,
does not want to depend upon it, or has VPN systems that do not universally
do IPv6 yet. (192.0.0.1 might be on-prem, but available via VPN)

As a different example:
   10.1.0.10
   2001:db8::10

in this case, anyone with IPv4 only should connect internally and/or via the
IPv4-only VPN.   But, the system/service is also available to those with IPv6
connectivity even if their VPN is off.
(There could be further ACLs on access which restricts which IPv6 sources
connect)
Should there also be a ULA for this service for devices that are internal,
and have internal IPv6 connectivity, and/or have IPv6 capable VPNs?

Note that putting RFC1918 in public DNS is frowned upon, and some home
routers (openwrt/dnsmasq) will filter them out as "rebind" attacks.
(It's a dumb name, but it's a real attack)

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide