Subject: Re: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-02

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 2 May 2009 19:54:45 +0200

On 30 apr 2009, at 9:19, Rémi Després wrote:

>> But what about people who run dual stack, and thus have no use for
>> NAT64 and thus not for a DNS64? They would see the ::ffff:0:0/96
>> addresses, which may get them to send normal IPv4 packets but there's
>> also a good change that it won't.

> - If they have IPv4 enabled they don't need NAT64.

Right, but when they do a AAAA lookup they get that ::ffff:0:0/96  
address, which could cause trouble for them.

Also, you would still have to have the DNS64 function becaus there is  
no way EVERYONE is going to add these addresses. So why not keep  
things simple and let NOBODY add them but have the DNS64 create the  
required AAAA records for NAT64?

>> For instance, the "mapped on the wire harmful" meme has been
>> percolating for half a decade and I'm willing to bet that at least
>> the NetBSD people filter this out in some way.

> This may be the case, but, if my proposal is accepted, this can be  
> fixed before mapped DNS64s need to stop translating mapped AAAAs  
> into ISP specific NAT64 prefixes (i.e. before IPv6-only to IPv4  
> connectivity has to be reconciled with DNSsec).

Even though hosts running IPv6 are at least not those that haven't  
been upgraded since 1998, it's still widely optimistic to assume that  
ANY change can be made to the deployed base within two years.

> In my understanding, if an intermediate DNS64 makes synthetic AAAAs,  
> it necessarily breaks the DNSsec provided guarantee that an RR that  
> is received does come from the DNS server of the host it points to.

Of course. A DNSSEC validator would recognize fake AAAA records as  
fake. That's the point of having DNSSEC. But it can tell that the A  
record is real and then perform the DNS64 function after the  
validation so if the DNSSEC validator knows about DNS64 there is no  
issue.

Iljitsch