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

[Brian E Carpenter <[e-mail]>]

On 2009-05-06 21:53, Xu Xiaohu wrote:
> 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, 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

> 
> Xiaohu
>  
> 
>> -----邮件原件-----
>> 发件人: [e-mail] [mailto:[e-mail]] 
>> 代表 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
>>
>>
>>
>>> 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
>>
>>> 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.
>>>
>>>
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave