Lorenzo Colitti <[email protected]> wrote: >> That solves the routing problem. But, what about the naming >> problem? (whose DNS server do you use?) >>
LC> NPT66 doesn't solve that either, right?
LC> I believe the DNS problem needs to be solved using split DNS at
LC> the domain level, because in the general case that you have more
LC> than one VPN there's no other way to do it.
I agree... NPT66 doesn't solve the problem. If I was forced to build
such a system, I would put a private copy of a stub resolver in my app,
and do DNS requests inside.
In the walled garden situation, however, if I had to hide the AAAA
records (which I think is fundamentally broken, but...), then I'd have
NS delegations from the public DNS into name servers that live in my
walled garden. So, you could see that my streaming TV system is at
walledgarden.tvservice.jp, but you couldn't resolve
server23.walledgareden.tvservice.jp.
>> Will this solution work if it's more than just your laptop? If
>> the VPN terminates on a gateway device?
>>
LC> This is a multihoming problem which needs to be solved anyway,
LC> and I think it can be solved using source/destination routing.
Agreed, which is why I brought it up. I'm trying to say that since it's
not enough to force the host always get it right, we need to make sure
we have a solution which improves when the host helps, but doesn't
depend upon it.
>> (Or, for instance, what about the virtual machines that you might
>> run on your laptop)
LC> If the VMs are bridged, it's no different from the multihoming
LC> problem. If they are not, then how are they going to get
LC> addresses?
In homenet, if we router where we bridged before, then it would be
routed. So, my virtualizer should learn to speak homenet routing
protocol. (go see what nvo3 wants them to do...)
--
Michael Richardson
-on the road-
pgpdWVDCWgYCs.pgp
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
