[dnsext] Some notes on ipv4/ipv6 co-existence

[Andrew Sullivan <[e-mail]>]

{No hat]

Dear colleagues,

I was planning to write up these notes in a more formal way, but it
seems these days that more work is going on the TODO than is coming
off it, so I thought I'd better send some remarks to the list instead.

In Dublin, you'll remember, the WG received a warning that "something
was coming" with respect to IPv4/IPv6 co-existence, and that we'd need
to keep our eyes peeled, but we didn't really know much more.

I attended an interim meeting on IPv4/IPv6 co-existence in Montreal at
the beginning of October.  There are a number of interesting proposals
on the table.

You can read about the meeting at
http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim.  The
minutes are there as well.

One class of proposals tries revivifying something like NAT-PT.  The
reason this is important for DNS is that these proposals all involve
some sort of translation of (for instance) A records into AAAA
records, in order to make resolution work (just as NAT-PT itself
did). 

Some documents that are useful reading:

http://tools.ietf.org/html/draft-wing-nat-pt-replacement-comparison

http://tools.ietf.org/html/draft-baker-behave-ivi
http://tools.ietf.org/html/draft-xli-behave-ivi
http://tools.ietf.org/html/draft-jennings-behave-nat6
http://tools.ietf.org/html/draft-bagnulo-behave-nat64
http://tools.ietf.org/html/draft-endo-v6ops-dnsproxy

It's worth pointing out that many of these appear to be relying on the
"dumb stub resolver" model.  So they add the "translation" function to
a "translation-enabled resolver" (thus avoiding the dangerous word
"DNS-ALG").  The DNSSEC implication is obvious: a validating
translator could validate the original response, then translate, and
hand the translated answer back to the stub.  This won't work for
validating end points, though, so there's going to be some trouble.
There are various clever answers to this being floated right now.  At
least some of the discussion is continuing on the v4v6interim mailing
list.  If you're interested in this topics, that wouldn't be a bad
list to watch.  One current suggestion (not in any draft I've yet
read, but I believe it came from Dan Wing) is to teach a validating
end node about the translation, and then allow it to "strip off" the
translation and validate that way; or (what I like better) not to
translate if the translator gets a signal that the end point can do it
on its own.

My experience at the meeting was very positive: for the most part, the
people proposing solutions were very receptive to concerns raised
about the potential DNS effects.  One area that I think may be a
potential area of some disagreement is on the very idea that
middleboxes should be altering the authoritative data before
responding to the client.  Many people seem to think that, since
split-brain has been deployed for a long time in corporate
environments, this is just a small change.  In any case, I think that
those attempting to get v4 and v6 networks talking to one another have
a clear understanding that there is potential harm that could come
from this, and they are actively seeking input from people with a DNS
background.  Therefore, if you can spare the time, it would be very
helpful to send comments and suggestions

I'm not sure that namedroppers is (yet) the right venue for discussion
of any of these proposals, although it's possible that they'll end up
as proposed working group items.  In the meantime, if you have any
questions about anything I may have said (or failed to say) at the
interim, please feel free to ask.

Best regards,

Andrew

-- 
Andrew Sullivan
[e-mail]
[phone] x104
http://www.commandprompt.com/

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>