Subject: Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 11:19:44 +0200

Hi Dave,

thanks for the comments

some replies below...

Dave Thaler escribió:
> Attached is a PDF with a bunch of detailed comments (and editorial nits)
> as markups.
>
> The main problem I have with this draft is that it requires changes in end
> nodes.  Contrary to what the abstract would have you believe, the draft
> clearly states in several places (sections 1.2.3 and 1.2.4 are the most
> prominent but other sections in the doc say the same thing) that it does
> require changes to dual-stack hosts (which is pretty much all recent hosts),
>   
more or less...
It does not _requires_ modifications cause the mechanism works with 
legacy hosts that do not implement this. However, host implementing this 
would benefit from using native connectivity when it is available. we 
thought this was a reasonable trade off.

i comment on you proposed alternative below...
> as well as to all nodes that implement DNSsec which means that this introduces
> another barrier to deployment of DNSsec just when we're trying to drive such
> deployment.
>
> As stated in my detailed comments (e.g. DT16,DT17,DT30), the former problem
> stems in part from the use of an arbitrary Pref64::/96 rather than the
> v4-mapped prefix being used as defined in RFC 2765, which would avoid
> the discovery problem, and the address sorting problem since it's already
> handled in RFC 3484.
>
>   
good point!

right, we had a long long discussion about this between the authors and 
we didn't reached consensus so we picked the majority preference :-)

However this argument that you bring was not considered

So the reasons why we thought a speparate prefix was needed is to be 
able to deal with intra site routing fluctuations. I mean, suppose that 
you have a site with multiple NAT64 boxes. Suppose that all of them are 
injecting the v4-mapped prefix into the intra site routing system. Now, 
suppose that one connection is established from a host1 in the v6 site 
and a binding is created in NAT1. NAT1 has a public v4 address IPv41. 
(since the binding was created in NAT1, this means that the intrasite 
routing system is routing the packets that the v6 host host1 is sending 
to the v4 world though NAT1).
suppose now that there is a routing fluctuation in the site routing. 
This can be a failure in one link. The failure is such that there is 
connectivity still (NAT1 is up and reachable) but within the new 
topology, NAT2 is now closer to host1 than NAT1. (NAT2 has a public v4 
address IPv42. The result is packets of the exsiting connection will now 
be routed through NAT2, and being presented to the v4 peer as coming 
from a different v4 address (before was IPv41 and now it is IPv42)

So, we concluded (sort of) that it was more important not to add new 
failure modes in the system.

(the main argument that we had about using a well know prefix that we 
had was that we wouldn't need to configure the Pref64, which is 
especially useful in the DNS64, resulting in a completelly decoupled 
functionality (i.e. with the current Pref64, there needs to be 
coordiantion between the pref64 used by the nat64 box and the prefx64 
used by the dns64 to generate the syntetic AAAA RR)

with the new argument that you provide, the new trade off is:
- allow legacy hosts to be sure to benefit from native connectivity 
whenever possible (and haivng compeltelly decoupled DNS64 - NAT64)
vs.
- insert additional failure modes.

It is a hard call. This depends on how often this failures are likely 
and how bad is the non-optimized option (i.e. using translated 
connectivity when native connectivity is available)

Now, with this background, what would be your take?

(BTW, we also discussed about using the v4-mapped prefix vs. defining a 
new prefix for this. People argued that v4-mapped prefixes must not be 
seen in the wire, so that we shouldn't use them in this way, what do you 
think about this. I mean, if we cannot use the v4 mapped prefix, we 
somehow loose part of this benefit, i guess, cuase we need to configure 
the new prefix in the policy tables, and i guess that the only deployed 
way to do this is manual config)

> And the latter problem (DNSsec) could only be assuaged slightly by clarifying
> the statements around DNSsec (comment DT29).  It seems to me that a node can
> be a "Non-Validating Security-Aware Stub Resolver" as defined in RFC 4033 and
> still "implement" DNSsec in the sense that it handles the AD bit (defined in
> RFC 4035) in a secure channel to the DNS64 server, and have no problems with
> the synthetic records. The DNS64 server would synthesize them after validation.
> It is only nodes that are Validating Resolvers that need to be modified.
>   
right
So we could support DNSSec in two modes, in the host itself and in the 
validating resolver, would that make sense to you? or do you think we 
should only support it in the validating resolver?

I address some of the comments that you made in the document below (the 
rest of the comments make also good points, but i we will address tham 
later, cause seems to go into the more speciics of the document)

Comment [DT3]: This sentence seems odd since
the draft doesn’t discuss this at all. It’s a side effect
of the “class of applications that work through
NATs”. Delete the sentence or else add a section in
the doc that talks about interaction with such
protocols. (I’d suggest deleting, for simplicity)

Well, this means that this is compatible with ICE and that p2p 
communication model works if ICE is used.
I mean, as currently defined, NAT64 needs some additional mechanism to 
support incoming communications, and ICE is an exsiting tool for that.
I think it is importnat to state that it is compatible with ICE, isn't it?

Later on

communications to an IPv4-only server.

Comment [DT4]: Is this talking about
a)An IPv6-only client app running on a dual-stack
node
b)A dual-stack node that couldn’t get any IPv4
addresses
c)A client that has no IPv4 stack
d)A dual-stack node that has both IPv4 and IPv6
addresses, but for whatever reason doesn’t have
IPv4 connectivity to the outside world
e)Some combination of the above ?
This confusion exists in multiple places in this doc.
One or more pictures would help significantly.

Right
I think this all mechanisms that are defined in this document works fine 
for a) b) and c) d). (c seems to me the more restrictive case in this 
scenario, right?)

OTOH, i don't think all the extnesions will work for c). For instance, 
IPSec support through the nat64, is likely to require that both node can 
parse the same protocol version, even if native connectivity is not 
available, so i would expect that IPSec communication will only be 
supported for d)

but i agree that this needs to be stated up front in the document

> -Dave Thaler

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Jul 2008 14:02:22 -0700

-Dave Thaler

---

From: Dave Thaler <[email-masked]>
Date: Fri, 18 Jul 2008 11:56:34 -0700

> thought this was a reasonable trade off.

I disagree.  If a dual-stack host is running an app that won't work
through a NAT, then it will not in fact work.  This is because as currently
written the draft will result in the synthetic IPv6 address being ordered
first.  Hence to avoid breaking lots of existing applications, it DOES
require modifications to all dual-stack nodes.

> failure modes in the system.

This is really no different from the use of many IPv4-to-IPv4 NATs
and firewalls today.  If you have a routing fluctuation that results
in a different NAT being used, your connection will go down.

> Now, with this background, what would be your take?

In my view it's a no-brainer...  keep it simple: just use the well-known
prefix.  The "additional failure modes" you refer to are already
well known (as are possible solutions by adding complexity within
the NAT/firewall middleboxes) and not a reason to cause problems for
end hosts.  Trying to deal with this by affecting end hosts just
adds additional complexity that reduces the chance anyone will want
to, or be able to, do it.

> seen in the wire, so that we shouldn't use them in this way, what do
> you think about this.

I don't buy any such argument.  The RFC 2765 (SIIT) defines them for use
on the wire, and is a Proposed Standard.
Get over it.  :)

> I mean, if we cannot use the v4 mapped prefix, we

I don't think there's any choice in that DNSsec defines both possibilities.
One of them is really easy for DNS64 deployment (change one box),
and the other is comparatively hard (change all the end nodes).
People will choose, but at least there's an easy option which makes
deployment a real possibility rather than an unlikely wish in my
opinion.

> the draft doesn't discuss this at all. It's a side effect
> of the "class of applications that work through
> NATs". Delete the sentence or else add a section in
> protocols. (I'd suggest deleting, for simplicity)
>

Only if you have a section in the document that explains this.

> b)A dual-stack node that couldn't get any IPv4
> addresses
> addresses, but for whatever reason doesn't have

I haven't thought through yet which of the mechanisms in the draft
might have additional issues in specific scenarios a-d.  It partly
depends on the choice of prefix we're discussing above, since the
use of something other than v4-mapped pulls in lots of extra
complexity that may have issues in specific scenarios.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 17:07:24 +0200

Dave Thaler escribió:
> Marcelo wrote:
>   
>> Hi Dave,
>>
>> thanks for the comments
>>
>> some replies below...
>>
>> Dave Thaler escribió:
>>     
>>> Attached is a PDF with a bunch of detailed comments (and editorial
>>>       
>> nits)
>>     
>>> as markups.
>>>
>>> The main problem I have with this draft is that it requires changes
>>>       
>> in end
>>     
>>> nodes.  Contrary to what the abstract would have you believe, the
>>>       
>> draft
>>     
>>> clearly states in several places (sections 1.2.3 and 1.2.4 are the
>>>       
>> most
>>     
>>> prominent but other sections in the doc say the same thing) that it
>>>       
>> does
>>     
>>> require changes to dual-stack hosts (which is pretty much all recent
>>>       
>> hosts),
>>     
>> more or less...
right

>>> as well as to all nodes that implement DNSsec which means that this
>>>       
>> introduces
>>     
>>> another barrier to deployment of DNSsec just when we're trying to
>>>       
>> drive such
>>     
>>> deployment.
>>>
>>> As stated in my detailed comments (e.g. DT16,DT17,DT30), the former
>>>       
>> problem
>>     
>>> stems in part from the use of an arbitrary Pref64::/96 rather than
>>>       
>> the
>>     
>>> the discovery problem, and the address sorting problem since it's
>>>       
>> already
>>     
>>> handled in RFC 3484.
>>>
>>>       
>> good point!
>>
ok, can buy all this and change the local Pref64 for the v4 mapped 
addresses (I am waiting for my co authors opinion though)

an additional benefit, is that now NAT64 and DNS64 are compeltelly decoupled

One more question:
If we use the v4 mapped prefixes, we can discover translated prefixes 
from the address itself (if it contains the v4 mapped prefix, it will be 
transalted)

So, do we still need the EDNS0 option?
I guess we don't, and that the DNSSec validation will depend on the 
prefix (i.e. if the response uses the v4 mapped prefix, then we can ask 
for the A RR and valdiate that and then infer the validity of the 
synthetic AAAA RR)

Actually, i like this option much more than the previous one, cause as 
you mention in your reivew, the current EDNS0 option marks the response 
and not the RR, which is bad cause the mark gets lost once the response 
is recived, In this way, we would actually mar the RR and would remain 
tagged as synthetic even once the response has been processed.
>>> And the latter problem (DNSsec) could only be assuaged slightly by
>>>       
>> clarifying
>>     
>>> the statements around DNSsec (comment DT29).  It seems to me that a
>>>       
>> node can
>>     
>>> be a "Non-Validating Security-Aware Stub Resolver" as defined in RFC
>>>       
>> 4033 and
>>     
>>> still "implement" DNSsec in the sense that it handles the AD bit
>>>       
>> (defined in
>>     
>>> RFC 4035) in a secure channel to the DNS64 server, and have no
>>>       
>> problems with
>>     
>>> the synthetic records. The DNS64 server would synthesize them after
>>>       
>> validation.
>>     
>>> It is only nodes that are Validating Resolvers that need to be
>>>       
>> modified.
>>     
>> right
sorry if i am a bit slow, so you think we must include both 
possibilties, right?

> Only if you have a section in the document that explains this.
We could include a section describing how ICE would work through a nat64 
box, do you think that would help?
Phillip has already done the excersise, so this is no problem

> complexity that may have issues in specific scenarios.
ok, let's talk about this once we have setteled the other major issues

Thanks, marcelo

---

From: Dave Thaler <[email-masked]>
Date: Sat, 19 Jul 2008 12:01:02 -0700

Marcelo writes:
[...]
> for the A RR and valdiate that and then infer the validity of the

Right, this is analogous to how a validating resolver handles
synthesized CNAMEs (see RFC 4035 section 4.8).

> tagged as synthetic even once the response has been processed.

Right.

[...]
> sorry if i am a bit slow, so you think we must include both

Yes.

[...]
> >> I think it is importnat to state that it is compatible with ICE,
> isn't
> >> it?
> >>
> >

Yes.

> ok, let's talk about this once we have setteled the other major issues

Sounds good.

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 15:24:36 +0200

> first.

Dual stack hosts shouldn't use synthetic AAAA records.

If the ENDS0 option is supported, then this will be avoided  
automatically. (This is of course a host change.) Until such time,  
it's important to make sure that dual stack hosts don't use a DNS64  
server as their DNS resolver.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 15:46:14 +0200

On 16 jul 2008, at 23:02, Dave Thaler wrote:

> the discovery problem

RFC 2765 is SIIT, which is a building block of RFC 2766 (NAT-PT). 2766  
uses a PREFIX variable rather than ::ffff:0:0/96.

Using ::ffff:0:0/96 rather than an arbitrary prefix has a number of  
advantages:

- no need for discovery, the prefix is always ::ffff:0:0/96

- faster failover after a failure

- no need for DNS64: the IPv6 socket API already translates IPv4  
addresses into ::ffff:0:0/96 addresses

- easy to accommodate IPv4-only applications

- no DNSSEC issues

- fewer NAT issues because network-conscious applications "know"  
they're talking to IPv4 destinations

- potentialy, SIIT can be easier because the address indicates an IPv4  
source/destination, so rather than translate ICMP to ICMPv6, just  
carry the IPv4 ICMP unmodified

However, I do think this would be harder to deploy because current  
implementations (most, if not all host OSes, maybe even some routers)  
make sure ::ffff:0:0/96 packets aren't allowed on the wire.

Also, some operators may be unhappy about seeing these packets that  
require a translator if they don't operate one.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Jul 2008 18:06:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iljitsch van Beijnum
> Sent: Sunday, July 20, 2008 6:25 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00
>

As a related point, going back to my comments that the draft needs
to clarify a dual-stack host on a v6-only network vs a node with
only an IPv6 stack.

If you have a v6-only network, then handing out a DNS64 server's
address in DHCPv6 as the DNS server is the right thing.

If you have a dual-stack network, then you'd really like to give
v6-only hosts a DNS64 server (e.g., via DHCPv6), but give dual-stack
hosts a DNS server.  This is a configuration problem.  Once you give
them the right address, v4mapped works fine for the ones using the
DNS64 server.  One example way to do this might be to have the
NAT-PT and the DNS64 box be the same machine, and use a v4-mapped
address as the DNS64 server address and give that IPv6 address
as the DNS server address to all clients.  Any packets arriving over
IPv4 must come from dual-stack nodes (and hence you don't synthesize
AAAA's), whereas any packets arriving over IPv6 must come from
V6-only nodes (and hence you synthesize AAAA's).

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 Jul 2008 11:11:37 +0200

> to clarify a dual-stack host on a v6-only network vs a node with

Sure.

However, until the next version, you can safely assume that "dual  
stack" goes to the host's connectivity, and that all hosts have an  
IPv4 stack on board.

> address in DHCPv6 as the DNS server is the right thing.

Or RFC 5006 or manual configuration.

> hosts a DNS server.

Right. This is the tricky part.

> One example way to do this might be to have the
> NAT-PT and the DNS64 box be the same machine,

For performance reasons, it's good if the DNS resolver is close to the  
clients or edges. NAT64 performance isn't dependent on RTT towards the  
clients, but here placement considerations include the availability of  
IPv4 connectivity, which will likely be limited in larger networks  
that deploy NAT64 so the NAT64 boxes would be closer to the network  
core or even borders.

Also, a multihomed site may want to be able to switch to NAT64s from  
different service providers without having to provision a new DNS64  
address to all clients in the site. So the DNS64 and NAT64  
functionality should be separate.

> and use a v4-mapped

Ah, that's an interesting trick. However, this very much depends on  
implementation particularities. As Marcelo posted on the intarea list  
yesterday:

http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html

we did some tests with MacOS 10.5 and Vista. (We couldn't do this with  
XP because it can't do DNS lookups over IPv6 transport and hence not  
function without IPv4 connectivity.) The result was that both systems  
would generate IPv4 traffic for AAAA records with mapped addresses  
when dual stack, but they would NOT generate any IPv6 traffic when  
running IPv6-only.

Also, if we're going with ::ffff:0:0/96 as the NAT64 prefix, there is  
no longer a need for DNS64 because resolver libraries already turn A  
records into v4-mapped addresses. (However, (some) hosts would need to  
be changed to do this even if there is no IPv4 connectivity.)
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 15:47:46 +0200

Dave Thaler escribió:
>>>> would benefit from using native connectivity when it is available.
>>>>         
>> we
>>     
right
however, i don't understand why for this work the dns64 and the nat64 
must be in the same device, could you expand on that?
regards, marcelo

---

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jul 2008 14:19:39 -0700

Marcelo writes:
[...]
> must be in the same device, could you expand on that?

I gave that as an example for simplicity since it's more obvious how
it would work.  They could be different but you'd need some other
weirdness like the IPv4 address and the corresponding v4-mapped address
being assigned to different devices, or some other way of communicating
to the DNS64 that the packet came through the NAT64, or whatever, and
was trying to just give an example, and it sounds like both Iljitsch
and you got the point of the example.

-Dave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jul 2008 22:09:20 -0400

Sorry about being late in joining this conversation.

When we were working on this draft, I originally argued strongly for  
using a single prefix for all NAT64s. The point that convinced me to  
change my mind and agree to use a unique prefix for each NAT64 was  
concerns over the mapping behavior that a NAT64 would demonstrate.

Say an ISP's network has multiple NAT64 devices, scattered across its  
various POPs, and consider an IPv6 node L in that network. It is VERY  
IMPORTANT that traffic from L destined for the IPv4 Internet always  
pass through the SAME  NAT64 device. If this is not the case; that is,  
if traffic from L destined to some IPv4 addresses passes through one  
NAT64 device and traffic from L destined to other IPv4 addresses pass  
through a different NAT64 device, then collectively it will appear as  
if L is behind a NAT with some sort of endpoint-dependent mapping  
property.  Endpoint-dependent NATs are very difficult to work with,  
and this will cause problems for NAT traversal schemes like ICE.

If each NAT64 is assigned a unique prefix, and if the DNS server  
queried by L always uses the same prefix to synthesize a AAAA record,  
then L will always use the same NAT64, and thus L will appear to be  
behind an endpoint-independent NAT.

However, if AAAA records are synthesized using a single prefix, as  
Dave is suggesting, then I think it is much harder to ensure that L  
always uses the same NAT64 device.

To be more precise, what we want is that all traffic from L uses one  
NAT64, but all traffic from another node M uses a different NAT64,  
etc, so that there is more-or-less an even assignment of nodes to  
NAT64 devices, with one node always using the same NAT64.

We need to solve this problem if we change to single prefix for  
synthesizing AAAA records.

- Philip

---

From: Dave Thaler <[email-masked]>
Date: Tue, 29 Jul 2008 04:44:47 -0700

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 3:09 AM
> To: Dave Thaler
> Cc: marcelo bagnulo braun; Iljitsch van Beijnum; [email-masked]

And my argument was that using different prefixes appears to require
changes to hosts (for reasons stated in the draft in the dual-stack-hosts
section).  Dealing with state synchronization or whatever between
NAT boxes is no different from stateful firewall problems today
and there are known techniques to address this which do not involve
changing the hosts.  Hence while I agree the problem should be
solved, it should not be done in a way that requires changes in
hosts.  The main value proposition of the NAT64 solution in my view
is for situations where you cannot change hosts on either side.

If you can change the hosts, then there are competing proposals
and it's not clear at this point that NAT64 is the best one for
this case, but it's a different scenario from the one that has
legacy hosts.

-Dave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jul 2008 14:59:57 +0300

> v6-only hosts a DNS64 server (e.g., via DHCPv6), but give dual-stack

Yes definitely. Doing otherwise would needlessly break a certain number of 
protocols/applications, I guess.

> This is a configuration problem.  Once you give them the right
> address, v4mapped works fine for the ones using the DNS64 server.

If we assume that all current v6-capable nodes are actually dual-stack... 
could we do it so that:

* On v6-only network, DNS64 is provisioned like normal (e.g. DHCPv6 and/or 
SLAAC) as "the" DNS recursive server.

* On a dual-stack network, DNS64 is provisioned with a *new* DNS64-specific 
setting (e.g. an extension to DHCPv6), and normal DNS is only provisioned via 
IPv4 (e.g. DHCPv4).

With such design, only the IPv6-only nodes need to be modified to understand 
the DNS64 option, and legacy/dual-stack nodes will ignore the DNS64. I don't 
think querying the DNS server over IPv4 is a practical problem on a 
dual-stack network.

Anyone?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jul 2008 15:33:15 +0300 (EEST)

This is mainly directed at Dave, but I'm responding off Remi's 
comment,

>> v6-only hosts a DNS64 server (e.g., via DHCPv6), but give dual-stack

How does the operator configuring DNS, DHCPv6, and/or Router 
Advertisements know whether a host is v6-only or dual-stack?

Note that a dual-stack host may also use DHCPv6 to request DNS server 
address information.  Such a host would probably also prefer those 
addresses over v4 DNS server addresses.

Do we also need to care about a scenario which has v6-only network and 
NAT64, but the user configures a v4-over-v6 tunnel or v6-in-v6 VPN and 
has connectivity and name lookup capability beyond what's provided by 
the physical network operator?

> setting (e.g. an extension to DHCPv6), and normal DNS is only provisioned via

Trying to figure out if this has implications on the "thou shalt not 
modify hosts" requirement (when examining dual-stack nodes in 
particular) makes my head ache :-/

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