Subject: v6ops-nat64-pb-statement-req: DNSSEC requirement

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Jul 2008 17:20:10 -0400

draft-ietf-v6ops-nat64-pb-statement-req-00.txt says:

>    R10: DNSSec support
> 
>    DNSSec support MUST NOT be prevented.
>    o  R10.1: In particular, if an IPv6 node is initiating a
>       communication with an IPv4 that is located behind a translator,
>       the IPv6 initiator MUST be able to perform DNSSec verification of
>       the DNS information of the IPv4 target. (strong consensus on this
>       one).

>    o  R10.2: In particular, if an IPv4 node is initiating a
>       communication with an IPv6 that is located behind a translator,
>       the IPv4 initiator MUST be able to perform DNSSec verification of
>       the DNS information of the IPv4 target.  This may require the
>       modification of the IPv4 node as well. (not clear if there
>       consensus on this one)

Maybe I don't understand what the above means, but it seems to me to
be unworkable. I.e., If an IPv6 node requests an AAAA record for an
IPv4-only node, there won't be a AAAA record and it will need to be
synthesized. By definition, such a synthesized DNS RR won't be
verifiable via DNSSEC because it is in fact an unauthorized
fabrication.

What am I missing here?

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Jul 2008 11:48:02 +0200

> verifiable via DNSSEC because it is in fact an unauthorized

That's true in an unmodified host that performs the DNSSEC validation  
itself.

If the DNSSEC validation is performed by a system that knows about  
NAT64 that system will reject the fake AAAA records by virtue of the  
EDNS0 SAS option (or simply because the validation fails) and can then  
retrieve the original A record and validate that.

Then, it can either conclude that the lower 32 bits of the fake AAAA  
record match the validated IPv4 address and allow the AAAA record, or  
determine the value of the 96 upper bits through a more secure  
mechanism and create a full 128-bit address that way.

The idea is that it's ok to break (some) stuff for existing systems as  
long as it's possible to fix this for updated systems.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 16:05:52 +0200

> verifiable via DNSSEC because it is in fact an unauthorized

if the verification is performed before the synthesis of the RR and 
there is a trsut relationship betwen the receiver and the node that has 
performed the verification and synthesis, this should do it. In 
particular, if everything happens at the end node, we are in business, 
right?
(i.e. the v6 end node asks for the A RR, perfomrs the dnssec validation 
and then internally generates the v6 address)

it is not so trivial for the v4 case though (actually i think it is not 
possible for the v4 case, hence the question mark)

Regards, marcelo

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Jul 2008 16:29:24 -0400

marcelo bagnulo braun <[email-masked]> writes:

> performed the verification and synthesis, this should do it.

Well, yes, but there are an awful lot of ifs in the above. Certainly
more than are appropriate for the original MUST requirement.

> In particular, if everything happens at the end node, we are in
> business, right?  (i.e. the v6 end node asks for the A RR, perfomrs
> the dnssec validation and then internally generates the v6 address)

Ahem. If the end node is doing this, why isn't it just doing dual
stack? After all, it (or rather the embedded translator) is sending
out IPv4...

> possible for the v4 case, hence the question mark)

In other words, the MUST needs some serious scoping. If it makes
sense at all.

I'm still not sure this requirement is acheivable in practice. So I'm
not at all sure it is appropriate to make it a MUST, at least not
without a lot more text explaining what is meant.

Thomas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 09:49:11 +0200

> more than are appropriate for the original MUST requirement.
but what i was describing here is a solution the describe that this is 
possible and so it makes sense to keep the requirement
there may be other solutions that also satisfy the requirement,
> stack? After all, it (or rather the embedded translator) is sending
cause the main scenario that we are targeting here is the case where the 
source node has no v4 address configured in its stack, so it cannot send 
v4 packets.

> I'm still not sure this requirement is acheivable in practice.
my take is that this is possible to achieve for v6 initiated 
communications (i.e. when AAAA RR are synthesized)
I don't think that it is achievable for v4 initiated communications 
(i.e. when A RR are synthesized)

I am lately thinking that we need two different lists of requirements 
one for v4 initiated communications and another one for v6 initiated 
communications especially for dealing with dns requirements. In v4 
initiated communications the state in the nat box has close relationship 
with the RR synthesis, while in v6 initiated communication they are 
completely decoupled, which makes possible to satisfy most of the dns 
requirements.

so, what do you think?

regards, marcelo

>  So I'm

---

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 24 Jul 2008 10:56:29 -0400

commenting to foster discussion in particular about the title and scope 
of the problem statement/requirement draft.  this has come up in other 
comments as well, in particular Rémi on 7/23.

It seems to me the problem statement needs to be general:  need for 
translation at some point in the network; the current title includes 
NAT64, which already makes some assumptions about solution approach.   I 
would rather see the problem statement (and title) generalized.  I like 
Rémi's suggestion of "IPv4/IPv6 Coexistence Scenarios - Requirements for 
Translation Mechanisms."

On the other hand, the requirements section of this draft would be a 
good place to start distinguishing among the solution approaches.  
Rather than spinning off separate documents (which we could always do at 
some future point) a sub-section for NAT64 specific requirements and 
another for NAT46 (at least) would be appropriate, and avoid duplication 
of general requirements that apply to both.  As it is there are already 
a lot of solution drafts circulating, and being discussed in too many 
places (behave, v6ops and intarea) to keep up.  I'm not complaining 
about the attention it is finally getting, because I strongly believe 
v4-v6 coexistence tools is a really big hurdle we need to clear, but I 
would like us to maintain focus on defining the problem and general 
requirements, and this draft seems to be the right place to do that.

I am assuming that NAT64=="v6 initiated communication" and NAT46=="v4 
initiated communication".  However a translator is built, it would have 
to be cognizant of particular requirements depending on which side 
initiates.  Restricting it to one or the other simplifies the problem, 
but this draft would not rule out an implementation that meets both.  I 
think Thomas's point that one set of requirements would need a lot of 
scoping language (do X if v6 initiated but X' if v4...) which would be 
easier to handle in two separate lists tailored to each.  Vertical 
rather than horizontal slicing...

edj

marcelo bagnulo braun wrote:
> Thomas Narten escribió:
>>  
>>> it is not so trivial for the v4 case though (actually i think it is 
>>> not possible for the v4 case, hence the question mark)
>>>     
>>
> initiated communications the state in the nat box has close 
> relationship with the RR synthesis, while in v6 initiated 
> communication they are completely decoupled, which makes possible to 
> satisfy most of the dns requirements.
>
> so, what do you think?
>
> regards, marcelo
>
>
>

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 11:10:32 +0200

Ed Jankiewicz escribió:
> commenting to foster discussion in particular about the title and 
> scope of the problem statement/requirement draft.  this has come up in 
> other comments as well, in particular Rémi on 7/23.
>
> NAT64, which already makes some assumptions about solution approach.   
> I would rather see the problem statement (and title) generalized.  I 
> like Rémi's suggestion of "IPv4/IPv6 Coexistence Scenarios - 
> Requirements for Translation Mechanisms."
will do then
> Rather than spinning off separate documents (which we could always do 
> at some future point) a sub-section for NAT64 specific requirements 
> and another for NAT46 (at least) would be appropriate, and avoid 
> duplication of general requirements that apply to both.
i will do a proposal for this in the ml and see what people think

>   As it is there are already a lot of solution drafts circulating, and 
> being discussed in too many places (behave, v6ops and intarea) to keep 
> up.  I'm not complaining about the attention it is finally getting, 
> because I strongly believe v4-v6 coexistence tools is a really big 
> hurdle we need to clear, but I would like us to maintain focus on 
> defining the problem and general requirements, and this draft seems to 
> be the right place to do that.
>
> initiated communication".  
mmm, i think the term has evolved
initially, i think that nat64 meant a new version of natpt but now we 
make a distinction between nat64 and nat46 as you say
we could expliclty state it this way in the document if you think so

> However a translator is built, it would have to be cognizant of 
> particular requirements depending on which side initiates.  
> Restricting it to one or the other simplifies the problem, but this 
> draft would not rule out an implementation that meets both.  I think 
> Thomas's point that one set of requirements would need a lot of 
ok, let me try to come up with something

regards, marcelo

---

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Jul 2008 08:15:04 -0400

> we could expliclty state it this way in the document if you think so

Yes. Clarity is good.

Thomas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 16:22:05 +0200

Thomas Narten escribió:
>> Thomas Narten escribiÃ³:
> Sorry, but no. if you have a simple MUST as a requirement, you can't
> have the solution involve a bunch of ifs that will not be true in
> general, and/or that change the meaning of meeting the requirement.
>
> DNSSEC is about e2e security. The recipient of the data (the DNS
> querier), using DNSSEC, is able to verify that the data has not been
> modified. This is no longer true in the solution outline you proposed
> above.
>   

How is that?
Suppose we have node H6 that is a v6 only node.
Suppose that node H6 wants to perform DNSSec validation
Suppose that it wants to initiate a communication with a node H4 that is 
v4 only
Suppose that node H6 makes a AAAA RR query for H4 and gets nothing and 
then it makes a A RR query and gets an IPv4 address.
Upon the recpetion of the A RR, it also obtains DNSec information to 
validate the A RR.
Node H6 then performs the DNSsec validation and then translates the H4 
address into an IPv6 address by prepending a /96 prefix.
Node H6 then sends IPv6 packet towards H4 which are translated into IPv4 
in a nat64 box soemwhere along the way

AFAIU, in this approach, DNSSec validation works e2e and we can state 
that this solution fulfills the proposed requirement to keep DNSSec working.

However, i don't think it is possible to make dnssec to work in the 
opposite direction, where the initiator is a v4 node.
Hence my suggestion to separate the v4 intiiated communication 
requirements from the v6 intiiated communication requirement.
(If what you are saying is that we cannot find a solution that would 
dnssec work for v4 initiated communications and that should be removed, 
i certianly agree)

In any case, many people expressed that a nat64 mechanism should not 
prevent dnssec from working (it is also true that these same people also 
expressed that for them having v4 intiiated communications was not a 
requirement)
The requirement contained in the draft is an attempt to express that
I am all for rewriting it in a better way, do you have any suggestion?

> Hence, the requirement needs to significantly expanded upon and/or
> clarified. Otherwise, people will assume it means X, when others
> assume it actually means Y.
>
>
>   
right, again, my proposal is to split the reqs one for v4 initiated and 
another list for v6 initiated, do you think this would do it?
other proposal for text?

> What exactly is the difference between a node that has no IPv4 address
> configured (so that it can not just use dual stack) and that same node
> with an embedded translator attached to it that does send out IPv4
> (after translation - and hence, has to have an IPv4 address
> configured)?
mmm, this is not what i described
What i described is a v6 node that locally generates the v6 address that 
maps the v4 address locally, but still sends only v6 packets.
The translation of packets is done on a different box

>  From what I can see, in both cases the node has an IPv4
> addresss and the directly attached network is IPv4 enabled. In that
> case, dual-stack seems like the obvious thing to use. I certainly
> wouldn't think a translater is needed here...
>   

i think we are talking about different cases here. I hope my description 
of what i had in mind above makes things clearer
> If the requirements are different in the two directions, then yes, two
> separate requirments are needed. You can't have a general requirement
> (that implicitely implies a solution in both directions) when a
> solution in one direction can't be made to work.
>   

that is what i think, but i would like to see if people agree with me.
For me the requirement that cannot be meet in the 46 direction (and that 
can be meet in the 64 direction) are those related to DNS.
In particular, DNSSec cannot work with 46 direction and

   R4: DNS semantics preservation

   Any modifications to DNS responses associated with translation MUST
   NOT violate standard DNS semantics.  This includes in particular that
   a DNS response (that has been modified by the translator mechanism)
   should not be invalid if it ends up in the wrong context, i.e.
   traversing a non expected part of the topology.

can't work neither cause the dns responses in the 46 cases are very context dependent cause the dns response contains the information associated to the nat46 state

regards, marcelo
PS: i am planning to send a mail describing the changes of the two req list in a moment

---

From: Thomas Narten <[email-masked]>
Date: Fri, 25 Jul 2008 08:22:14 -0400

configured)? From what I can see, in both cases the node has an IPv4

Thomas

---

From: Rémi Després <[email-masked]>
Date: Fri, 25 Jul 2008 17:00:20 +0200

Thomas Narten  - Le 7/25/08 2:15 PM :
>>> I am assuming that NAT64=="v6 initiated communication" and
>>> NAT46=="v4 initiated communication".
> 
>> mmm, i think the term has evolved initially, i think that nat64
>> meant a new version of natpt but now we make a distinction between
>> nat64 and nat46 as you say we could expliclty state it this way in
>> the document if you think so
> 
> Yes. Clarity is good.
Indeed.

Note that, using RFC 2663's terminology,  the distinction is more precisely:
- NAT64: IPv6 internal side, IPv4 external side
- NAT46: IPv4 internal side, IPv6 external side

(NATs that do port forwarding support connections initiated from both
sides.)

Regards.

Rémi Després

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jul 2008 10:24:35 +1200

> - NAT46: IPv4 internal side, IPv6 external side

Where do you find that in 2663?

In any case I think the notions of "internal" and
"external" are not well-defined in a network which
mixes regions of pure IPv6, regions of pure IPv4
and dual-stack regions. Also, NAT terminology tends to
be based on the distinction between private ambiguous
and public global addresses, which makes no sense
for IPv6.

> (NATs that do port forwarding support connections initiated from both

Exactly. I don't think this can be reduced to two acronyms.

     Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 26 Jul 2008 09:14:26 +0200

Brian E Carpenter  - Le 7/26/08 12:24 AM :
>> Note that, using RFC 2663's terminology,  the distinction is more 
>> precisely: - NAT64: IPv6 internal side, IPv4 external side - NAT46:
>> IPv4 internal side, IPv6 external side
> 

In the introduction:
"network's internal IP addresses cannot be used outside the network 
either because they are invalid for use outside, or because the internal 
addressing must be kept private from the external network."

  Another way to say it is that addresses that need translation are 
those of hosts in the internal side network.
  They are translated as source addresses in the internal to external 
direction, as destination addresses in the external to internal direction.

> In any case I think the notions of "internal" and "external" are not
> well-defined in a network which mixes regions of pure IPv6, regions
> of pure IPv4 and dual-stack regions. Also, NAT terminology tends to 
> be based on the distinction between private ambiguous and public
> global addresses, which makes no sense for IPv6.
> 
>> (NATs that do port forwarding support connections initiated from
>> both sides.)
> 

I also find that more precise acronyms could be useful.
For example, private IPv4 address spaces (RFC 1918), say 4p, could 
advantageously be distinguished from the global IPv4 address space, say 4g.

Thus:
- NAT4p6 and NAT64g can be cascaded to be equivalent to a NAT4p4g for 
connections initiated by 4p hosts (no DNS ALG needed).
- In the reverse cascade, NAT4g6-NAT64p, the NAT 4g6 has the problem 
that, for connections initiated by 4g hosts, there is no stateless 
translation of 4g addresses into routable v6 addresses.

Regards

Rémi Després

---

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Jul 2008 13:13:02 +0300 (EEST)

> and public global addresses, which makes no sense

FWIW, it's possible to build a router (or NAT) that has a single 
logical interface.  The draft assumes at least two interfaces.  Not 
that such boxes are very widely deployed in practise.. :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Jul 2008 23:02:32 +0100

> modified. This is no longer true in the solution outline you proposed

I assume you mean NAT64/DNS64.

Actually it works as designed: someone in the middle changes the DNS  
records and the DNS records no longer validate.

If you want to use DNSSEC and NAT64 together, either DNSSEC or DNS64  
must be changed to be aware of the other. Yes, this is inconvenient  
but then again, not being able to connect to the 99% of the internet  
that's still on IPv4 when your ISP can't give you an IPv4 address  
anymore is also quite inconvenient.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jul 2008 09:48:01 +0300 (EEST)

On Sun, 27 Jul 2008, Iljitsch van Beijnum wrote:
> If you want to use DNSSEC and NAT64 together, either DNSSEC or DNS64 must be 
> changed to be aware of the other.

(This is a side note wrt the subject change..) Well, you could make 
the v6-hosts query A records, and synthethize themselves based on 
NAT64 prefix information they have.  Not sure if you count this in 
either of your categories above.

> Yes, this is inconvenient but then again, 
> not being able to connect to the 99% of the internet that's still on IPv4 
> when your ISP can't give you an IPv4 address anymore is also quite 
> inconvenient.

This is a belief that needs debunking. Many drafts, this included, 
make the assumption that there is major incentive to deploy v6 before 
IANA's v4 space runs out.  Some longer sighted ISPs may see it so 
especially if the IETF and vendors can provide tools to assist them; 
others won't. The ISP will just provide the users private address 
space and do NAT.  This has been commonplace in many 2G/3G 
deployments, and it will become the norm in residential connectivity 
as well.  So the scenario we must compare NAT64 etc. against is 
ISP-provided v4 private space, not no v4 at all.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Jul 2008 20:38:29 +1200

On 2008-07-28 18:48, Pekka Savola wrote:
>> must be changed to be aware of the other.
> 
> (This is a side note wrt the subject change..) Well, you could make the
> v6-hosts query A records, and synthethize themselves based on NAT64
> prefix information they have.  Not sure if you count this in either of
> your categories above.

I think some of us have been calling this a "lying resolver" that
transforms A replies into AAAA replies. The resolver could extend its
lie, by validating the A reply and pretending that the synthetic AAAA
was validated.

However, that requires the IPv6 resolver to be modified, i.e. a
host modification.

    Brian