BOUNCE v6ops@ops.ietf.org: Non-member submission from [Michael Richardson <mcr@sandelman.ottawa.on.ca>] (fwd)

[Kurtis Lindqvist <kurtis@kurtis.pp.se>]

From mcr@marajade.sandelman.ca Wed Apr 02 02:35:28 2008
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>
Date: Tue, 01 Apr 2008 19:54:16 -0400
Message-ID: <9248.1207094056@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 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.
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?


- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBR/LK9YCLcPvd0N1lAQLSAAgAnTJeLYlVCfnW3hX+0lj//DCAIWQMBgiy
ebJ0D/d/qM6MyiG96h2XnPN8hXErvP+qOYkjggZ2/fFcB7WvzfhOQICob+c6QAsJ
Ux5qgpSDTm+qTL3zViNdb5A75d9xqVALvipyTfm1YiEUhe2SkaQka4aWMUNVl8Ie
HW8tTrY4hAFME+coBWiMF20ZGuuBDm3O88zlHCg0NkYAppKV2gTXKOTaP8mggQ1A
Fk7lRGLVKRvt+apcVFUk7DV8YLM6Djj7lSod6mlDzGmgan0xAIMwH+QpQZCE+YbU
1Jbj/o8N2X/EW8PevQOdgM9wYH0Zhr+MURFzzJwtdrbCI0I7l8wbFA==
=IcJX
-----END PGP SIGNATURE-----