Re: [Int-area] practical issues with using v4-mapped addresses fornat64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Int-area] practical issues with using v4-mapped addresses fornat64
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 aFrom int-area-bounces at ietf.org Fri Jul 25 02:23:16 2008
Return-Path: <int-area-bounces at ietf.org>
X-Original-To: int-area-archive at megatron.ietf.org
Delivered-To: ietfarch-int-area-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 95F2E3A689D;
Fri, 25 Jul 2008 02:23:16 -0700 (PDT)
X-Original-To: int-area at core3.amsl.com
Delivered-To: int-area at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B5C2C3A689D
for <int-area at core3.amsl.com>; Fri, 25 Jul 2008 02:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id cRCuE1vfz9xC for <int-area at core3.amsl.com>;
Fri, 25 Jul 2008 02:23:13 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1])
by core3.amsl.com (Postfix) with ESMTP id D4C513A6899
for <int-area at ietf.org>; Fri, 25 Jul 2008 02:23:12 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1])
by netcore.fi (8.13.8/8.13.8) with ESMTP id m6P9N3sd027548;
Fri, 25 Jul 2008 12:23:03 +0300
Received: from localhost (pekkas at localhost)
by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6P9N0kl027538;
Fri, 25 Jul 2008 12:23:01 +0300
Date: Fri, 25 Jul 2008 12:23:00 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: marcelo bagnulo braun <marcelo at it.uc3m.es>
In-Reply-To: <4889814F.1000604 at it.uc3m.es>
Message-ID: <alpine.LRH.1.10.0807251124310.26103 at netcore.fi>
References: <48846C5B.2050602 at it.uc3m.es><E9CACA3D8417CE409FE3669AAE1E5A4F04
589BDD87 at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><F7F81ECB-FD
B
F-401A-82D9-FEB27E638C41 at muada.com><alpine.LRH.1.10.0807240820540.23361 at n
et core.fi><02018E7E-07E4-40F7-9A16-F53C43E6813C at muada.com>
<alpine.LRH.1.10.0807250808510.21379 at netcore.fi>
<4889814F.1000604 at it.uc3m.es>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.93.1/7818/Thu Jul 24 23:42:11 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: "int-area at ietf.org" <int-area at ietf.org>,
Philip Matthews <philip_matthews at magma.ca>
Subject: Re: [Int-area] practical issues with using v4-mapped addresses
fornat64
X-BeenThere: int-area at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area at ietf.org>
List-Help: <mailto:int-area-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org
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 spe 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 cial 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.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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area
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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
