Hi Pekka,
Pekka Savola escribió:
On Thu, 24 Jul 2008, Iljitsch van Beijnum wrote:
last IETF meeting, there was a NAT-PT translator present. So I could
browse the web, connect to Jabber, send/receive email etc even though
the servers didn't have IPv6 addresses.
...
On the other hand, this can also be accomplished with an arbitrary
prefix if the host knows the prefix and intercepts API calls that
would normally generate IPv4 packets but turn those into IPv6 packets
towards the translator if there is no IPv4 connectivity.
Exactly! As you demonstrated, host stacks needs to be modified no
matter what.
well, not really
If you use a local prefix as currently done, you don't need to modify
the hosts, right?
If you choose a prefix that is supposed to be "well known" (used by
all implementations), you could overload the existing use of mapped
addresses, or choose something else altogether. Given that you can't
depend on the existing behaviour of mapped addresses anyway, if you go
this "fixed address block" route, the least astonishing failure modes
could be achieved with a new special prefix.
the problem that Dave has pointed out, is that if you use a local
prefix, the dual stack hosts can't tell if there is native connectivity
or translated connectivity and that if they select translated
connectivity the apps that don't work through nats would break.
the goal is to solve that
using mapped prefixes was one option, but i understand that it doesn't
work for legacy hosts, so no arguing with that
the next question is what about v4 compatible prefix? could we use that
one?
the benefit of this one is that it is also in the defaul policy table in
rfc3484 and it then allows dula stack hosts to preffer native
connectivity than translated connectivity,
Now, as you say, the node could also signal the prefix somehow. As
Julien Laganier wrote, these kind of deployments (with faithd, totd,
etc.) have already been used for a long time. As the prefix is
dependant on the network, there are no source spoofing, routing table
pollution, etc. problems.
I would like to understand which are all these problems in more detail
could you expand in source spoofing and in route pollution?
If you don't signal anything, the result is that you spew out packets
with the mapped addresses with the assumption that there is going to
be a translator somewhere along the path that's going to do something
to them.
not really you would only generate packets towards a v4mapped (or any
prefix selected for nat64) if you have receive a synthetic AAAA RR for
that destiantion, which only happens if you have a dns64 which should
only happen if you have a nat64 in the path
Otherwise they end up transiting enterprise and backbone networks and
potentially arriving at the destination which does something
unexpected with that, e.g. discard them or end up waiting in
SYN-RECEIVED state. IMO, it seems better to not send packets out
unless you know they are going to be useful for someone.
What seems to be missing is a good way to signal the prefix and some
modifications to API calls.
i understand the need for signalling the prefix, what do you need an api
call for? how do you deal with legacy dual stack hosts to not use
translated connecitivity when native is available?
regards, marcelo
As demonstrated, stack modifications are already needed (at least in
API handling), so why not do it all the way?
As a source address, if the node(s) on link are also provided with
real IPv6 addresses, this would be indistinguishable from source
address spoofing.
Only translators would transmit packets with v4mapped source
addresses, so this isn't much of an issue.
(I thought the mapped addresses would have been used between a host
and a translator -- or, if there doesn't happen to be translator, the
packets would end up in the destination network. But maybe not..)
So we're required to trust that anyone running a translator in the
Internet is honest netizen?
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
