[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ocean: do not boil
At 05:58 AM 9/24/02, Hesham Soliman (EAB) wrote:
> p2p applications can be designed to use intermediaries,
> just like SMTP and HTTP. If I was designing an apps
> protocol today, I would definitely make sure it could
> be relayed between address spaces at applications level.
=> Are we in a position to mandate this?
We're not in a position to _mandate_ anything. However, we are
in a position to make recommendations about the best way to resolve
Say we have a scenario that runs like this:
HostA is an IPv6-only node in an IPv6-only network in SiteA.
HostA wants to reach ServiceB which runs on HostB in SiteB, an
IPv4-only service on an IPv4-only node in an IPv4-only network.
Now what are the possible solutions to that scenario?
We could say that the best solution for this scenario is to install
a NAT-PT-like box at the border of SiteA, modify the resolver in
HostA (or the DNS server for SiteA) so that HostA will receive special
IPv4-mapped addresses instead of A records for IPv4-only hosts,
insert special routes to send packets to those addresses to the
NAT-PT-like box, and translate traffic to those addresses from
IPv6->IPv4 at the border of SiteA.
We could say that the NAT-PT-like box should be installed at the
border of SiteB, AAAA DNS entries should be advertised for the
IPv4-only hosts within SiteB, routes should be advertised to cause
IPv6 traffic to those addresses to come to NAT-PT-like box on the
border of SiteB, and packets will be translated from IPv6->IPv4
at that border.
Or, we could simply suggest that, if people want to reach IPv4-only
services from a given host, they should support IPv4 connectivity to
that host. This would mean installing a dual-stack on HostA and
providing IPv4 connectivity (perhaps via NAT if IPv4 address space is
an issue) within SiteA.
We can suggest any one of these solutions, and people are, of course,
entitled to ignore us. Given the choice between these three, though,
the third one seems simpler and less prone to introducing new
architectural and application-level issues, since the IPv4 infrastructure
would be exactly the same as what many people are using today.