Maybe I shouldn't have stuck my finger on this because it seems I
don't have a clear idea what are the scenarios being discussed. I
hope this gets clarified in some document at some point..
On Fri, 25 Jul 2008, marcelo bagnulo braun wrote:
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?
Right (at least modify in this respect), my above comment was written
in the context using the mapped addresses.
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.
Are we discussing a scenario where a v6-only host is in a network
where the link it attaches to has no v4 (but further upstream there
could be but necessarily isn't)? If so (there is no fallback possible
to v4) there is no point in giving the host another prefix unless
you're at the same time able to signal how it's special and that it's
in fact being used in the network for something. This seems to call
for something like a DHCPv6 option. The same DHCPv6 message exchange
could deploy address selection policies to the host.
Or are we talking about "local prefix" in the sense, "DNS-ALG will use
the local prefix to change responses, but the prefix isn't used to
assign addresses on a host" ?
the goal is to solve 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 default policy table in
rfc3484 and it then allows dula stack hosts to preffer native connectivity
than translated connectivity,
Compatible is slightly better because it doesn't overload existing
non-obsoleted addressing mechanism. But still -- what would be the
benefit of a host sending packets out with v4 compatible destination
addresses if it doesn't know that some translator is going to do
something with them? Are you assuming either that translators would
be prevalent enough that attempting such communication would be
feasible? Or that it doesn't cause that much harm? Or something
else? My point here is that there already should be a requirement to
signal the presence of a translator in the network, and if there is,
we could piggyback the rest of the configuration with that.
Maybe an important distinction is whether your peers (or those wishing
to initiate sessions to you) also need to understand the prefix, and
if so, why. (Why isn't obvious to me at the moment because usually
they don't have alternatives to choose from.) On the other hand, it's
easier if only the host and/or the local site needs to understand the
prefix.
I would like to understand which are all these problems in more detail
could you expand in source spoofing and in route pollution?
How does the first hop router verify that a packet with a special
source address was correctly sent (to the same level of correctness as
available with unicast RPF check on the router or proposed SAVI WG
mechanisms)?
If such packets are forwarded beyond the first hop router (e.g., from
an enterprise network to ISP), how does the ISP verify that the
enterprise is not sending junk with addresses it doesn't have (e.g.
flooding attacks)?
Or are the special source addresses routable back to the networks
originating them? (If they aren't how could such one-way
communication be useful?) If they are routable, wouldn't this more or
less require that v6 BGP and routing would also need to route these
special prefixes for all the v4 prefixes currently or previously
used?
The result could be that the core routers would need to carry IPv4
routing table, IPv6 native routing table and IPv6 embedded routing
table (a subset of v4 routing table).
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?
Not sure about the API. I guess it depends on how you deploy the
name->address mapping. I guess the host could also query both and
synthetize a response. This might imply API modifications. You could
possibly do without them with a different placement of mapping
function. Not sure whether/how the application would need to be able
to signal its interest for v4/v6-pure/v6-translated connectivity --
maybe the stack can figure it out on its own.
Wrt legacy dual stack, it doesn't feel like a strong requirement to be
able to avoid modifications to v6 code. Deploying local v6 policies
is already existing code though (not sure of its practicability).
If you don't deploy additional addresses to hosts, the only point of
consideration is when a mapping function like DNS would return
multiple entries -- for a v6-only host, a v6-only response requires no
change. v4-only response requires translation, but the host has no
alternative so that's trivial. A v6+v4 response could be either a)
left as is, b) augmented to v6+v4trans+v4, c) changed to v6+v4trans,
or d) v4 removed, ie. changed to just v6. In this case, if v6
connectivity would work OK to destinations advertising v6 connectivity
(I suspect it should if you're willing to deploy v6-only hosts and
networks!), a) or d) could both be viable options and there is no
selection problem.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
