[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT64 and DNSSec
- To: v6ops@ops.ietf.org
- Subject: Re: NAT64 and DNSSec
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Wed, 09 Apr 2008 16:36:57 +1200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fcMagMPZljh1GQ7U8o2LAh/xNxMbuyEUkcIGaz/xnKGbyVvDRIXT1nJIVe+iUP8AqylsfnO15i+I3ojO6eS8HBAn9iBITfUgBaKiIsboIE+ju3m8Orm2sabsBmHSgYxAknwewQtdt8BrRLkmHZGqbQp8RF1vgrHwD+2vt3gYkqE=
- In-reply-to: <20080408220621.B42797@lemland.kurtis.pp.se>
- Organization: University of Auckland
- References: <20080408220621.B42797@lemland.kurtis.pp.se>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
> From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
> To: marcelo bagnulo <marcelo@it.uc3m.es>
> cc: v6ops@ops.ietf.org, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
> joao@isc.org, Iljitsch van Beijnum <iljitsch@muada.com>,
> Liman Lars-Johan <liman@autonomica.se>,
> =?ISO-8859-1?Q?Ihr=E9n_Johan?= <johani@autonomica.se>,
> Mark_Andrews@isc.org
> Subject: Re: NAT64 and DNSSec
> In-Reply-To: <47EA94A0.20503@it.uc3m.es>
> References: <47EA94A0.20503@it.uc3m.es>
> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19)
> Date: Tue, 01 Apr 2008 19:54:16 -0400
> Message-ID: <9248.1207094056@marajade.sandelman.ca>
> Sender: mcr@marajade.sandelman.ca
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> okay, so I don't understand the problem, I think. I read the thread.
> Are you talking about a v4v6v4 mechanism?
>
> I don't see a problem for v4 nodes that are DNSSEC enabled
> talking to v4 nodes out there. Everything should just work.
>
> The issue is I see is when an "educated" v6 node in the
> v6-part of the v4v6v4 cloud wants to talk to a v4-only node
> that is out there. That's was where, I think, the thought
> that we need a synthetic AAAA record is.
>
> It seems to me that the problem is resolved if we apply the end-to-end
> principle: the end-node needs to do the work. No hacking the data in
> the middle.
That is a fine sentiment, but doesn't apply if the target system
is a "legacy" RFC2460 IPv6 node.
>
> That means that any AAAA record synthesis needs to happen in the
> end-node, (in the resolver library if appropriate for that OS), *AFTER*
> the DNSSEC has been done.
>
> And this is necessary only for v6-only nodes.
> v4/v6 nodes do nothing --- they just act as v4 nodes and experience
> v4/v6/v4.
>
> I don't believe the "v4-initiated" situation is real.
That depends on deployment scenarios over the next ten years
or so that are hard to predict.
> I do believe that v6->v4 NAT-PT is critical to making v6 deployable ---
> the ROI for putting the v6 into the small device in a home is that you
> can yank out the complicated v4 goop. Combined with a NAT-PT in a
> home-router and 6to4 on it. But that requires synthesized AAAA.
>
> I didn't understand Iljitsch's comments:
>
>>>>>> "Iljitsch" == Iljitsch van Beijnum <iljitsch@muada.com> writes:
> Iljitsch> This is the rationale behind working with A records rather
> Iljitsch> than fake AAAA records in MNAT-PT. This makes most of the
> Iljitsch> compatibility issues go away, at the cost of having to
> Iljitsch> come up with a mechanism to distribute the /96 for the
> Iljitsch> translator to the hosts in question and implementing this
> Iljitsch> mechanism and some other logic in the IPv6 hosts.
>
> perhaps I need a reference to a draft/RFC?
draft-van-beijnum-v6ops-mnat-pt-00
Brian