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

[Rémi Després <[e-mail]>]

Iljitsch van Beijnum  -  le (m/j/a) 4/29/09 8:34 PM:
> On 29 apr 2009, at 9:46, Rémi Després wrote:
> 
>> If these OSes send mapped addresses on the wire when their dual
>> stack has IPv4 enabled, they don't comply with RFC 2553 sec 3.7:
> 
> They don't, they send IPv4 packets, if anything.

Good remark.
A better statement to support the proposal could have been:
"If they have IPv4 enabled, dual stack OSes that comply with RFC 2553 
sec 3.7 send IPv4 packets when  mapped-address destinations are 
presented to their IPv6 socket interfaces".


>> The important point though, is IMHO that, in addition to alignment
>> of OSes with RFC 2553, DNS64s SHOULD in the short term replace
>> mapped addresses by addresses in the provider range
> 
> So what you want is that:
> 
> 1. ::ffff:0:0/96 becomes the NAT64 WKP 2. People running IPv4-only
> hosts put ::ffff:a.b.c.d AAAA records in the DNS 3. People running
> IPv6-only deploy NAT64s and DNS64s 4. DNS64s translate these AAAA
> records into a local (provider address space) NAT64 AAAA record

Yes, this is what I propose, with a few more details on when to do what, 
in a previous answer to Keith Moore (ref. 
www.ietf.org/mail-archive/web/behave/current/msg05890).


> 
> 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.
- If they only their non-updated OSes are assigned only IPv6 addresses 
without having also NAT64s and DNS64s operational, they have no way to 
reach IPv4-only hosts, independently of which DNS RRs are where.

(If an IPv6-only network has to permit non-updated hosts to reach 
IPv4-only servers, it MUST have NAT64s and DNS64s.)

> 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).


> Also, this is completely unnecessary. The DNS64 can create the fake
> AAAA records from the A records just as easily as from mapped AAAA
> records,
> 
>> These DNS64s should also be ready to disable this replacement when 
>> DNSsec compatibility becomes desirable.

1. The proposal is not that DNS64s stop making synthetic AAAAs with 
ISP-specific prefixes when they do it with received As, it is that they 
ALSO do it with received AAAAs.

2. In my understanding, if (1) DNS64s stop making synthetic AAAAs, (2)
IPv4-only servers have no AAAAs in their DNS servers, then IPv6-only to 
IPv4-only connectivity is broken.


> A much simpler way to be compatible with DNSSEC is to simply update
> the DNSSEC validators. Since the DNS64 functionality is new, having
> an integrated DNS64/DNSSEC validator is not a deployment issue.
> DNSSEC validation on the hosts is virtually non-existant, so
> requiring an update to those is not the worst thing in the world and
> certainly easier than upgrading all IPv6 stacks to change their
> mapped address behavior.

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.


> Note by the way that the idea of mapping the ::ffff:0:0/96 prefix to
> the NAT64 prefix has some merit, I've suggested things along these
> lines a while ago.

This IMHO supports that time has come to revisit this subject, to be 
sure very carefully, but without any paralyzing taboo.


> If a host doesn't have IPv4 connectivity it could perform this
> mapping, which has the advantage that real A records can be used and
> that the host thinks it's doing IPv4, not IPv6, so it can do stuff 
> like enabling IPv4 NAT traversal. But this should be done in the
> host, which knows if there is IPv4 connectivity or not.
> 
> On the other hand, may as well use the softwire stuff for this...

The SAM approach is proposed separately is IMHO in this direction, but 
this is another objective. The scenario for which specification of 
NAT64s and DNS64s is considered is, in my understanding, that of 
IPv4-only servers being reached by non-updated IPv6-only hosts 
(including by non-updated dual stack hosts having IPv6-only addresses).

Regards,

RD