Subject: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64

From: Rémi Després <[email-masked]>
Date: Mon, 04 May 2009 18:54:40 +0200

Fred, Marcello, Iljitsch, Dan, Keith

We have exchanged various mails recently concerning the relationship
between IPv6-only hosts, NAT64, DNSsec.

After one more simplification (DNS64 discarding mapped-address AAAAs
rather than translating them), here is an updated proposal.

The objective is that:

O1: If an IPv6-only client that performs DNSsec validation wishes to
establish connections with an IPv4-only server whose address is DNSsec
signed (in both its A and mapped-address AAAA formats), it should
eventually be able to receive the signed AAAA so that it can validate it.

O2: If an IPv6-only client that doesn't perform DNSsec validation
receives, for an IPv4-only server, both a DNS64 synthesized AAAA and a
mapped-address AAAA, it should use the synthetic AAAA as an effect of
the existing longest match rule.

O3: If a dual stack host (with both IPv6 and IPv4 enabled so that it
really acts as dual stack) receives, for an IPv4-only server, both an A
and a mapped-address AAAA, it should communicate in IPv4 as an effect of
existing preferences (for IPv6 addresses over IPv4 addresses if both are
available, and for the IPv4 stack over the IPv6 stack if the destination
address is an IPv4 mapped address - according to RFCs 3484 and RFC 2553
respectively).

Rules proposed to reach the objective are as follows:

(1) IN THE SHORT TERM:

R1: DNS64s MUST silently discard mapped-address AAAAs they receive.

R2: At the first (non urgent) opportunity, dual stack OSes that don't
act as follows, MUST be updated to do it:
(a) If IPv4 is enabled, datagrams presented at the socket interface with
an IPv4 mapped-address as destination MUST be sent in IPv4 (RFC 2553 sec
3.7)
(b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6.
(Relinquishment of an old but unjustified taboo which seems to have
prevented some OSes to act this way.)

(2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY WITH R2 (no
urgency)

R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in their
DNS servers (in addition to As).

R4: Independently, DNS64s MAY start to forward mapped-address AAAAs
(either all of them for simplicity or, if more selectively, ensuring
that all those that are DNSsec signed are indeed forwarded).

In my understanding, these (simple) rules are sufficient to eventually
reconcile NAT64s with DNSsec in IPv6-only hosts. And they are so far the
only ones I know for this.

If the analysis is right, advices on how to proceed would be welcome. (A
possibility would be to add appropriate sentences in
draft-baker-behave-v4v6-framework and draft-bagnulo-behave-dns64.)

If the analysis is wrong, it's IMHO worth understanding where.

Regards,

RD

PS: apologies to addressees for the retransmission. I had forgotten the 
copy to th emailing list.

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 May 2009 17:43:29 +0800

> O3: If a dual stack host (with both IPv6 and IPv4 enabled so 
> that it really acts as dual stack) receives, for an IPv4-only 
> server, both an A and a mapped-address AAAA, it should 
> communicate in IPv4 as an effect of existing preferences (for 
> IPv6 addresses over IPv4 addresses if both are available, and 
> for the IPv4 stack over the IPv6 stack if the destination 
> address is an IPv4 mapped address - according to RFCs 3484 
> and RFC 2553 respectively).

Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only hosts
and dual-stack hosts wihin an IPv6 network is also a scenario in which it's
better to allow the hosts, especially those IPv6 only hosts to learn the
prefix64 and synthesize the IPv6 addresses for destination IPv4 hosts on
demands, rather than depending on the DNS64 to synthesize AAAA records from
A records no matter the client is IPv6 only or dual stack.Make sense?

Xiaohu

> R2: At the first (non urgent) opportunity, dual stack OSes 
> that don't act as follows, MUST be updated to do it:
> (a) If IPv4 is enabled, datagrams presented at the socket 
> interface with an IPv4 mapped-address as destination MUST be 
> sent in IPv4 (RFC 2553 sec
> 3.7)
> (Relinquishment of an old but unjustified taboo which seems 
> to have prevented some OSes to act this way.)
> 
> 
> R3: IPv4-only hosts MAY start advertising mapped-address 
> AAAAs in their DNS servers (in addition to As).
> 
> R4: Independently, DNS64s MAY start to forward mapped-address 
> AAAAs (either all of them for simplicity or, if more 
> selectively, ensuring that all those that are DNSsec signed 
> are indeed forwarded).
> 
> 
> 
> In my understanding, these (simple) rules are sufficient to 
> eventually reconcile NAT64s with DNSsec in IPv6-only hosts. 
> And they are so far the only ones I know for this.
> 
> If the analysis is right, advices on how to proceed would be 
> welcome. (A possibility would be to add appropriate sentences 
> in draft-baker-behave-v4v6-framework and draft-bagnulo-behave-dns64.)
> 
> PS: apologies to addressees for the retransmission. I had 
> forgotten the copy to th emailing list.
> 
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 May 2009 17:53:53 +0800

Sorry, there was a mistake in the previous email, please see the corrected
text.

Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only hosts
and dual-stack hosts wihin an IPv6 network is also a scenario in which it's
better to allow the hosts, especially those DUAL-STACK hosts to learn the
prefix64 and synthesize the IPv6 addresses for destination IPv4 hosts on
demands, rather than depending on the DNS64 to synthesize AAAA records from
A records no matter the client is IPv6 only or dual-stack.Make sense?

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 
> 代表 Xu Xiaohu
> 发送时间: 2009年5月6日 17:43
> 收件人: 'Rémi Després'; 'Fred Baker'; 'Marcello Bagnulo Braun'; 
> 'Iljitsch van Beijnum'; 'Dan Wing'; 'Keith Moore'; 'Behave WG'
> 主题: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding 
> mapped AAAAs inDNS64
> 
> 
> 
> > really acts as dual stack) receives, for an IPv4-only 
> server, both an 
> > A and a mapped-address AAAA, it should communicate in IPv4 as an 
> > effect of existing preferences (for
> > IPv6 addresses over IPv4 addresses if both are available, 
> and for the 
> > IPv4 stack over the IPv6 stack if the destination address 
> is an IPv4 
> > mapped address - according to RFCs 3484 and RFC 2553 respectively).
> 
> Except of the DNSSEC and P2P scenarios, the coexistance of 
> IPv6-only hosts and dual-stack hosts wihin an IPv6 network is 
> also a scenario in which it's better to allow the hosts, 
> especially those IPv6 only hosts to learn the
> prefix64 and synthesize the IPv6 addresses for destination 
> IPv4 hosts on demands, rather than depending on the DNS64 to 
> synthesize AAAA records from A records no matter the client 
> is IPv6 only or dual stack.Make sense?
> 
> Xiaohu
> 
> that don't 
> > (a) If IPv4 is enabled, datagrams presented at the socket interface 
> > with an IPv4 mapped-address as destination MUST be sent in 
> IPv4 (RFC 
> > 2553 sec
> > 3.7)
> > R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in 
> > their DNS servers (in addition to As).
> >

---

From: Rémi Després <[email-masked]>
Date: Wed, 06 May 2009 15:05:07 +0200

Xu Xiaohu  -  le (m/j/a) 5/6/09 11:53 AM:
> Sorry, there was a mistake in the previous email, please see the 
> corrected text.
> 
> Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only 
> hosts and dual-stack hosts wihin an IPv6 network is also a scenario 
> in which it's better to allow the hosts, especially those DUAL-STACK 
> hosts to learn the prefix64 and synthesize the IPv6 addresses for 
> destination IPv4 hosts on demands, rather than depending on the DNS64
>  to synthesize AAAA records from A records no matter the client is 
> IPv6 only or dual-stack.Make sense?

Yes, it makes sense to me.

There should be IMHO one more constraint:
- If prefix64 is not the mapped-address prefix, synthesis of AAAAs MUST
be performed ONLY if no IPv4 address is locally enabled.
(Otherwise, a dual-stack application in a dual-stack host that has an
IPv4 address enabled may end up using IPv6 although IPv4 is possible and
no NAT64 is available).

In my understanding, the effect is that IPv6-only applications, if they
are in dual-stack hosts having only IPv6 addresses can reach IPv4-only
servers via NAT64s.

What I propose concerns only hosts that are purely IPv6. (They cannot
synthesize AAAAs from As because, being supposed not to query for As,
they don't receive any). The new rule is then a complement which
concerns dual stack hosts in IPv6 networks. Agreed?

RD

>>> that don't act as follows, MUST be updated to do it: (a) If IPv4 is
>>> enabled, datagrams presented at the socket interface with an IPv4 
>>> mapped-address as destination MUST be sent in IPv4 (RFC 2553 sec
>>>  3.7) (b) If IPv4 is not enabled, these datagrams MUST be sent in
>>>  IPv6. (Relinquishment of an old but unjustified taboo which
>>> seems to have prevented some OSes to act this way.)
>>> 
>>> 
>>> (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY WITH R2
>>>  (no urgency)
>>> 
>>> AAAAs (either all of them for simplicity or, if more selectively,
>>>  ensuring that all those that are DNSsec signed are indeed 
>>> forwarded).
>>> 
>>> 
>>> 
>>> eventually reconcile NAT64s with DNSsec in IPv6-only hosts. And 
>>> they are so far the only ones I know for this.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 May 2009 07:14:19 +1000

In message <[email-masked]>, =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= write
> concerns dual stack hosts in IPv6 networks. Agreed?

	Not querying for A's on a IPv6 only host when there are no
	AAAA's is idiotic.  The same is true in reverse.  Lots of
	problems have been caused by that rule.  You need to know
	whether a host exists or not *and* whether it is reachable
	or not.  This is especially true when search lists are
	involved.  You want the unqualified name to refer to the
	same machine whether you are IPv4 only, dual stack or IPv6
	only.

	One could add MX and SRV (basename) to the list as well.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 May 2009 09:34:33 +1200

> A records no matter the client is IPv6 only or dual-stack.Make sense?

Yes, but you're assuming that the IP stacks in the hosts can be modified
from basic (RFC2460) behaviour. We certainly need to deal with hosts
that only contain a standard resolver, so a DNS64 remains essential
for that case.

We discussed this in draft-van-beijnum-v6ops-mnat-pt last year,
and I don't think the situation has changed much.

   Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 07 May 2009 10:32:26 +0800

> 代表 Brian E Carpenter
> 发送时间: 2009年5月7日 5:35
> 收件人: Xu Xiaohu
> 抄送: 'Behave WG'; 'Keith Moore'; 'Fred Baker'; 'Dan Wing'
> mapped AAAAs in DNS64
> IPv6-only 
> > hosts and dual-stack hosts wihin an IPv6 network is also a 
> scenario in 
> > which it's better to allow the hosts, especially those DUAL-STACK 
> > hosts to learn the
> IPv4 hosts 
> > on demands, rather than depending on the DNS64 to synthesize AAAA 
> > records from A records no matter the client is IPv6 only or 
> dual-stack.Make sense?
> 
> Yes, but you're assuming that the IP stacks in the hosts can 
> be modified from basic (RFC2460) behaviour. We certainly need 
> to deal with hosts that only contain a standard resolver, so 
> a DNS64 remains essential for that case.

Yes, both of them have their own application scenarios.
 
> We discussed this in draft-van-beijnum-v6ops-mnat-pt last 
> year, and I don't think the situation has changed much.

Thanks for this information.

Xiaohu

> mapped AAAAs 
> >> inDNS64
> IPv6-only 
> >> in which it's better to allow the hosts, especially those 
> IPv6 only 
> >> hosts to learn the
> >> synthesize AAAA records from A records no matter the 
> client is IPv6 
> >> only or dual stack.Make sense?
> >>
> >> Xiaohu
> >>
> interface 
> >>> welcome. (A possibility would be to add appropriate sentences in

---

From: Rémi Després <[email-masked]>
Date: Thu, 07 May 2009 10:44:12 +0200

Mark Andrews  -  le (m/j/a) 5/6/09 11:14 PM:
> In message <[email-masked]>, 
> =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= write s:
>> What I propose concerns only hosts that are purely IPv6. (They 
>> cannot synthesize AAAAs from As because, being supposed not to 
>> query for As, they don't receive any). The new rule is then a 
>> complement which concerns dual stack hosts in IPv6 networks. 
>> Agreed?

> Not querying for A's on a IPv6 only host when there are no AAAA's is
>  idiotic.

What has been clearly missing is a common understanding of what is a
"purely IPv6" host. It was understood to be "a host in which nothing 
reflects that IPv4 ever existed". (A host that has a dual stack OS and 
only an IPv6 local address is NOT "purely IPv6".)

With this understanding, it is supposing that a purely IPv6 host queries 
for As that becomes... what you say ;-).

Working now on "purely IPv6" hosts may look premature to some, in view 
of other priorities, but doing it while working on transition strategies 
should at least not be considered unreasonable.

> The same is true in reverse.

I didn't get the point. Clarification?

> Lots of problems have been caused by that rule.

Which rule?

> You need to know whether a host exists or not *and* whether it is
> reachable or not. This is especially true when search lists are
> involved.  You want the unqualified name to refer to the same machine
> whether you are IPv4 only, dual stack or IPv6 only.

Agreed

> One could add MX and SRV (basename) to the list as well.

Agreed.

Regards,
RD

---

From: William Waites <[email-masked]>
Date: Sat, 9 May 2009 13:00:24 +0200

> IPv4 address enabled may end up using IPv6 although IPv4 is possible and

I'd rather say something like, "ONLY if there is no IPv4 route to the
destination". That way if I have a private or island IPv4 network
address on an interface I can still use a translator to talk to remote
IPv4 hosts where there is no native connectivity.

Note that on my "IPv6 only" hosts I still have, for example, 127.0.0.1
configured on the loopback interface.

-w
-- 
William Waites
+49 30 8894 9942

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 May 2009 16:32:04 +0200

> configured on the loopback interface.

It should be clear that in a dual-stack host having an IPv4 loopback 
interface is not sufficient for IPv4 to be enabled.

Note that RFC 2765 defines an IPv4 enabled node as "A node which has an 
IPv4 protocol stack and is assigned one or more IPv4 addresses."

It is worth clarifying that 127.0.0.1 must not be taken as an "assigned" 
address.

Regards,

RD

---

From: William Waites <[email-masked]>
Date: Wed, 13 May 2009 12:46:36 +0200

> It is worth clarifying that 127.0.0.1 must not be taken as an "assigned"

That would help but I think we need to go further. A host may
be connected to a private IPv4 network and yet only have IPv6
connectivity to the global Internet. In this circumstance
address translation should be used for networks that are
unreachable with IPv4. Unreachable means there is no route
to them in the host's tables, having an IPv4 address or not is
not sufficient information with which to make the decision.

Cheers,
-w
-- 
William Waites
+49 30 8894 9942

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 May 2009 11:56:07 +0200

William Waites  -  le (m/j/a) 5/13/09 12:46 PM:
>> It should be clear that in a dual-stack host having an IPv4
>> loopback interface is not sufficient for IPv4 to be enabled.
>> 
>> It is worth clarifying that 127.0.0.1 must not be taken as an
>> "assigned" address.
> 
> That would help but I think we need to go further. A host may be
> connected to a private IPv4 network and yet only have IPv6 
> connectivity to the global Internet.

IMHO, no one should deploy an IPv4 network with global IPv6 connectivity 
and no IPv4 NAT somewhere to provide also IPv4 connectivity (be it 
limited because of NAT traversal).

I therefore don't see (so far) a need for any additional complexity for 
this scenario.

> In this circumstance address translation should be used for networks
> that are unreachable with IPv4. Unreachable means there is no route 
> to them in the host's tables, having an IPv4 address or not is not
> sufficient information with which to make the decision.
> 
> Cheers, -w

---

From: William Waites <[email-masked]>
Date: Fri, 22 May 2009 16:03:47 +0200

On Wed, May 20, 2009 at 11:56:07AM +0200, RRRmi Desprrrs wrote:
> and no IPv4 NAT somewhere to provide also IPv4 connectivity (be it limited 
> because of NAT traversal).

My ISP finally gives me native only IPv6 and they have a NAT64
somewhere for me to use. (Hooray!)

On my home network I have a printer that only speaks IPv4.

How do I print something I found on a web site?

-w

---

From: "Gabor Bajko" <[email-masked]>
Date: Sat, 23 May 2009 12:41:41 -0700

Hello,

I have a terminology question regarding the above draft:
The draft uses the 'IPv6-only client' and 'IPv4-only server' terminologies,
and it was not immediately clear to me what they mean, as they are not
defined in the terminology section.

I found though this text in section 1: " ... a lot of IPv6-only clients will
want
   to connect to IPv4-only servers.  These include hosts running IPv6-
   only applications, IPv6-only hosts as well as the cases where only
   IPv6-only connectivity is available between the client and the NAT64."

I wonder if a similar description would be valid for the 'IPv4-only server',
ie 'a server running IPv4 applications, IPv4-only servers as well as the
cases where only IPv4 connectivity is available between the server and the
NAT64' (I regard a server not a fixed node, any mobile node can become a
server, eg when hosts services).

When I have a dual stack node running IPv4 only applications but provisioned
with IPv6 address only, would that classify it as an 'IPv6-only client' in
this context?

Similarly, when I have a dual stack server, running only IPv6 applications,
but attached to a network where it can only get an IPv4 address, would the
node become an 'IPv4-only server' in this context?

Thanks,
- Gabor

---

From: Dave Thaler <[email-masked]>
Date: Sat, 30 May 2009 01:55:14 +0000

> server, eg when hosts services).

Yes.

> with IPv6 address only, would that classify it as an 'IPv6-only client'

No, it would classify as a "nothing" client, since that application
has neither IPv4 nor IPv6 connectivity (unless you have some translation
scheme in the host like BIS or BIA as I mentioned in my presentation
at the interim meeting:
ftp://ftpeng.cisco.com/dwing/behave/TranslationInHost.pdf )

> node become an 'IPv4-only server' in this context?

No, it'd be a "nothing" server, unless you have some translation
scheme in the host such as AF_INET6 sockets with v4-mapped addresses.

-Dave