[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT64 and DNSSec



Iljitsch van Beijnum escribió:
On 28 mrt 2008, at 17:33, marcelo bagnulo wrote:

For v6->v4, the IPv4 address is mapped to IPv6 space locally.

what do you mean by locally?

This:

I.e., if you connect to the network elsewhere, you see a different mapping.

If I connect to ISP A I'd probably see 2001:A::FFFF:0:0/96 as the translator prefix and if I then move to ISP B the translator prefix there would be something like 2001:A::FFFF:0:0/96. So the 6->4 mapping is a local matter.

On the other hand, if for v4 we assume that there is only a single IPv4 address that maps to a single IPv6 address (or v4/port to v6/port) because there aren't enough v4 addresses to have several of them map to the same v4 address, the IPv4->IPv6 mapping is globally unique so it can be published in the DNS. This also means that the records can be signed so there shouldn't be a DNSSEC issue. (Note though that this requires DNS records TBD. See the MNAT-PT draft for what this _could_ look like.)

i don't have a preference here, but i am nore focused in the requirements that we can impose right now. Do you think it would be possible to impose any form of requirement for using DNSSec in the v4 host?

Well, for v6->v4 we currently have the synthetic AAAA records. A translator that doesn't use these is possible in this direction, and even likely in the v4->v6 direction because we don't have an existing spec that uses synthetic records for that direction.

I don't understand this
Are you saying that we don't have synthetic A records. What about section 4.1. of RFC 2766?

What we may not need are synthetic AAAA records, since we can assing a fixed IPv6 address to any v4 address, but we will need synthetic A records, and these are the ones that can hardly verified using DNSSec even if we upgrade the v4 side to do some special DNSSec magic, since it woudl require communication with the NAT64 box.
Am i misisng something here?

Regards, marcelo

Even if we use the DNS for this synthetic A records seem unlikely so there shouldn't be DNSSEC issues. Although if we use additional records to aid in the transition we'd probably want those to be signed too if the original FQDN->A mapping is signed, but since the path through the hierarchy must be different (the FQDN isn't available to the translator so it has to do some kind of PTR lookup) this could be fairly non-trivial.