Subject: Re: [BEHAVE] I-D Action:draft-bagnulo-behave-nat64-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2008 10:32:10 +1200

Hi,

> 1.2.2.  Walkthough
...
>    The local name server needs to know the /96 prefix assigned to the
>    local NAT64 (Pref64::/96).  For the purpose of this example, we
>    assume it learns this through manual configuration.

I believe that quite a bit more discussion is needed about
the assumed topology. Because of this configuration requirement
(or any reasonable assumptions about a discovery protocol) it seems
likely that the IPv6 host, the NAT64 and the DNS64 must be in the
same administrative domain. If not, how can things be managed
securely?

> 3.1.  Synthentic AAAA RRs
...
>    TBD: Do we always want synthetic RRs to have a TTL of 0?  Is it ever
>    reasonable or desirable to cache them?

In fact I think it's highly desirable to cache them. It seems extremely
common that the same name is resolved locally numerous times in succession
within a few seconds or a few minutes. What is the problem with a TTL
that is always less than the binding lifetime in the NAT64?

> 3.3.  DNS64
...
>    If this query results in an empty result or in
>    an error, this result is returned to the client.  

Even in this case, the result has to be synthetic I think
(original AAAA query followed by empty answer or error).

BTW, what about inverse queries?

>    To ensure endpoint-independent mapping behavior, a given IPv6 host
>    must always use the same NAT64.  

I don't understand why this matters. As long as a given flow uses
the same {DNS64,NAT64} pair, why would it matter? (This is linked
to the TTL question - if the TTL is zero, it surely can't matter.
If there is a TTL, it matters until the TTL expires.)

...
>    Furthermore, it is highly desirable to synthesize the AAAA records as
>    close as possible to the host that will use them.  This helps ensure
>    that a given host always uses the same NAT64.

Again, why does it matter? It's using a consistent {DNS64,NAT64} pair
that matters.
...
>    TBD: What does a DNS64 do when a query for an A record returns a
>    CNAME record and an A record?  The SAS option, as currently defined,
>    flags ALL records in the answer section as synthetic.  Does the DNS64
>    return just a CNAME record?  Does it return just an AAAA record?  Or
>    does it return a real CNAME record and a synthetic AAAA record in the
>    answer section -- something that the current rules do not allow.

The last one seems obviously correct, so why not change the rules?

Finally a general point. As far as I can see there is no problem
with a scenario like

IPv6----NAT64--(public addresses)--NAT44--(private addresses)--IPv4

and it seems quite likely to a frequent case. It's probably worth
noting that this will work correctly.

     Brian

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Jun 2008 09:52:59 +0200

Hi Brian,

thanks for the comments

see replies below...

Brian E Carpenter escribió:
> the assumed topology.

maybe
>  Because of this configuration requirement
What i had in mind is that the NAT64 and that the DNS64 need to have 
some form of trust relationship, since the DNS64 needs to generate the 
synthetic AAAA RR including the Pref64 of the NAT64 box, so there must 
be a way to convey the Pref64 to the DNS64 securely. One option is as 
you say that the NAT64 and the DNS64 are in the same domain, so there is 
some implicit trust there (but there can be others, Iljitsch was 
proposing some dhcp option to convey the pref64 and it could be manually 
configured)

However, i am not sure i see the need for the IPv6 host to be in the 
same domain than the NAT64 and the DNS64...

Suppose the following configuration

+----------------+
| IPv6 ISP       |
|            +-------+    +--------+
|            |  NAT64|----|  IPv4  | 
|            |  DNS64|    |Internet|
|            +-------+    +--------+
|                |
+----------------+
        |
   +---------+
   | v6 site |
   |         |
   | v6 host |
   +---------+

I think this should work fine
The v6 ISP is announcing to the v6 site either a default route either 
its prefix (whcih contains Pref64 for his NAT64)

Do you think there is an issue here?

> that is always less than the binding lifetime in the NAT64?
No, i don't think there is a problem in the general case, but the NAT64 
may be down or some other wierd things can happen that would make this fail

Actually the proposal to make TTL 0 is more a general design 
consideration than a measure to deal with a specific issue
The synthetic AAAA RR should not be around much cause they are synthetic 
and we thought (especially i thought :-) that they should disappear asap

> (original AAAA query followed by empty answer or error).
don't know
why do you think this is needed?

> BTW, what about inverse queries?
good point!
I guess that the DNS64 should handle those and i think this should be 
possible, since the Pref64 belong to the site.
But we need to figure this out indeed

> If there is a TTL, it matters until the TTL expires.)
But if a given host uses two different NAT64 it would appear to the v4 
world with two different IP addresses and that would somehow be 
incompatible with endpoint indepedence?
Maybe this is stretching the definition of endpoint indepdence a bit too 
much, cause endpoint independence is about a single nat box?

> Again, why does it matter? It's using a consistent {DNS64,NAT64} pair

same than above

> The last one seems obviously correct, so why not change the rules?
right
at this point we wanted to keep the draft as simple as possible
when we start adding support for specific cases, complexity grows 
immediately and nobody can follow the draft :-)

we could add some flags to the sas option

we been through this path and we end up with quite complicated 
interaction between flags, caching servers and other elements.

I mean, this is an optimization, since the host could get the CNAME and 
then query for the AAAA RR and get the synthetic AAAA RR back with the 
SAS option

IMHO, we need to identify which are the relevant cases and support 
optimizations for that, but for all cases

so if people think this is one of the relevant cases, we can do that

> noting that this will work correctly.
I understand that the communication is initiated from the v6 host, right?

If so, this is supported with ICE, isn't it?

I mean how else it is possible to open a hole in the nat44 to receive 
incoming communications?

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2008 10:03:02 +1200

Comments in line...

On 2008-06-17 19:52, marcelo bagnulo braun wrote:
> |            |  NAT64|----|  IPv4  | |            |  DNS64|    |Internet|
> |            +-------+    +--------+
> |                |
> +----------------+
>        |
>   +---------+
>   | v6 site |
>   |         |
>   | v6 host |
>   +---------+
> 

I think it will work. My concern is how the v6 host knows to use this
particular {DNS64,NAT64} pair if it is not under the same admin.
We don't want it to be a guessing game like finding a Teredo server or
6to4 relay. So it has to be administratively configured or there has
to be a solid discovery protocol.

> may be down or some other wierd things can happen that would make this fail

Sure, but then the packets will be blackholed and that is no worse
than when your default router or a normal NAT dies, as far as I can see.
Obviously the TTL should be small in any case.

> and we thought (especially i thought :-) that they should disappear asap

I think that's too strong. I think they must disappear within a reasonable
time, but I think zero is unreasonable.

> why do you think this is needed?

I don't fully understand what DNS error replies look like,
but I think they include the original query type. If so, the
resolver code might get confused if the error reply to a AAAA
query contained query type A.

> much, cause endpoint independence is about a single nat box?

Yes, and I don't see anything in today's world that says a given
host must consistently use the same NAT for different upper layer
sessions.

> so if people think this is one of the relevant cases, we can do that

Agreed.

> I understand that the communication is initiated from the v6 host, right?

Yes

> I mean how else it is possible to open a hole in the nat44 to receive

Absolutely. My only point is to add a small note that from the IPv4
viewpoint, this scenario works just as well or badly as without NAT64.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jun 2008 15:39:53 -0700

... 
> host must consistently use the same NAT for different upper layer

In early BEHAVE meetings it was pointed out that some HTTP 
applications expected to see all connections from the same user
to be from the same IP address, and that some HTTP applications 
set cookies that include the source IP address (directly, or
hashed); technorati.com is one such site, but I have no idea the
purpose of the cookie that includes my IP address ("tvisitor").  
If other TCP connections come from a different IP address, 
those applications *might not* function as desired / intended.

And while not IETF sanctioned, some mail servers do still use 
pop-before-smtp <http://popbsmtp.sourceforge.net> in lieu of 
SMTP AUTH.  Pop-before-smtp authorizes an IP address to do
an SMTP submission if a pop (or imap) login occured from that 
same IP address within the last "n" minutes.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2008 10:57:06 +1200

> those applications *might not* function as desired / intended.

Yes, but that applies if my ISP changes my public IP address
when I restart my ADSL box, among other cases. So it's certainly
a NAT-induced risk of inconsistency, but not really a new one.

This suggests a SHOULD requirement to use the same NAT64 but
not a MUST.
> same IP address within the last "n" minutes.

Good heavens. Well, again a SHOULD case I think.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jun 2008 16:00:10 -0700

> a NAT-induced risk of inconsistency, but not really a new one.

That doesn't happen very often.  But to take the other extreme with
NAT64, if the public IP address is changing for every outgoing TCP 
connection, it would be happening very often.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Jun 2008 14:05:05 +0200

below...

> particular {DNS64,NAT64} pair if it is not under the same admin.
As i see it, the v6 site will try to resolve the AAAA RR query.
This needs to be intercepted by the DNS64.
There are many ways this can happen
one option is that the ISP has a DNS64 in its DNS server, and that the 
v6 host at the end sites is using DNS services from the ISP, that would 
work fine i think
The other option is that the v6 site has a its own dns server and in 
that case, DNS64 in the ISP needs to intercept all the queries that it 
generates. this basically means that the DNS64 must be place in the 
right part of the ISP topology. Once that the DNS64 has generated the 
synthetic AAAA RR with a given Pref64, this is assoicated to a given 
NAT64 box and the traffic will be routed through that nat64 box.
Finally another option is that the DNS server of the IPv6 site implement 
the DNS64 functionality. In this case it needs to discover the PRef64 of 
the NAT64 box which is located in the ISP. One option is to configre 
this manually. As i mention earlier, it would be possible (and not very 
difficult) to define a dhacp extension for this (similar to the prefix 
delegation)

> to be a solid discovery protocol.
would the above options make sense to you?

> Obviously the TTL should be small in any case.
but the point is there may be multiple nat64 box each one with a 
different pref64 and if a host still uses the pref64 of the box that is 
down, it won't be getting connectivity even though it could

> time, but I think zero is unreasonable.
ok, if i am the only one that feels this way, we can change this :-(

> query contained query type A.
ok, let's get some dns experts to look at this

> host must consistently use the same NAT for different upper layer
well, endpoint independence requirement kind of does. I mean, endpoint 
independence states that two different sessions with the same source 
transport address should use the same nat mapping even if the 
destiantion transport address change. So, it somehow implies thtat 
different connections from the same process need to use the same nat, i 
think

> viewpoint, this scenario works just as well or badly as without NAT64.

right, this is what we meant when stating that the mechanism supported 
p2p communications, but we c
an include a more descriptive text and example

Thanks, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2008 09:50:04 +1200

below below...

> would the above options make sense to you?

Yes. Effectivley you are using DNS as the DNS64 discovery protocol,
and then DNS64 as the NAT64 discovery protocol. So there is a rule that
the DNS64 and the NAT64 MUST be configured as a pair. I think the
document should describe the above scenarios, with a normative statement
that one of them MUST be used.

> down, it won't be getting connectivity even though it could

Correct, which why the TTL must certainly be quite short.

> ok, if i am the only one that feels this way, we can change this :-(

How about saying that the TTL MAY be zero and MUST be less than N?
Then we can have an argument about the value of N ;-)

> different connections from the same process need to use the same nat, i

Since I believe that this is unenforceable I think it can at most
be a SHOULD. I agree that in an ideal world it would be MUST, but
that's not where we live ;-)

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Jun 2008 20:46:43 +0200

> that one of them MUST be used.
ok, will do that

> Then we can have an argument about the value of N ;-)
any suggestion to kick off the disucssion?

> that's not where we live ;-)
well we can try to enforce nats having endpoint independent behavior 
(actually nat64 tries to do that, i hope it achieves it) but in the case 
you mention, i.e. two differnet applications it is more than just nat 
behaviour i guess, but also host behaviour sand DNS is also involved, it 
can be harder i agree.

so, i would go for a must in the endpoint independence in the nat itself 
and a should in the case that involves other components, like the dns64 
and the host itself (because of the reasons that you mention)

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jun 2008 15:52:00 +1200

On 2008-06-21 06:46, marcelo bagnulo braun wrote:
...
> any suggestion to kick off the disucssion?

Is there a lifetime that BEHAVE recommends for NAT binding state
lifetime? It would seem that the DNS64 TTL should be less
than that.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 21 Jun 2008 12:03:42 +0200

Brian E Carpenter escribió:
> lifetime?

my understanding is that this depends on whether the binding was for UDP 
traffic or for TCP traffic

for UDP the min is 2 min and the reccomended value is 5 min afaiu
For TCP is like 2 hours, but of course you can discard binding state if 
the nat see a fin exchange

>  It would seem that the DNS64 TTL should be less
> than that.
>
>   
1 or 2 min?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Jun 2008 10:56:08 +1200

>>  It would seem that the DNS64 TTL should be less

Or maybe 100 seconds, so it is less than the minimum for UDP?
(For example, imagine a streaming protocol that has a glitch after
90 seconds - it seems safe to use the cached synthetic AAAA then,
because the NAT64 will still have binding state for UDP, so will
not even know that the host had a glitch. After 120 seconds, it's
safer to restart with completely fresh state.)

So my full proposal is that the TTL MAY be zero, and MUST NOT
exceed 100 seconds, and obviously MUST NOT exceed the remaining TTL
of the original A record.

That should cover cases where a host resolves the same name
repeatedly over a period of a few seconds, which is what I was
concerned about.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Jun 2008 10:13:18 +0200

> repeatedly over a period of a few seconds, which is what I was
I am ok with that

thanks, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 15:08:43 +0200

> This needs to be intercepted by the DNS64.

I don't like this terminology; it's too ALG-y.

We don't want to intercept DNS requests, we want to put a DNS64  
somewhere in the DNS resolution hierarchy.

> v6 host at the end sites is using DNS services from the ISP, that  

Right.

> generates.

If by this you mean that all DNS packets to/from the site are  
intercepted by the ISP, I very much disagree.

If the site has its own DNS server, either this DNS server must  
perform the DNS64 function locally (then it needs to know a /96 for  
one or more NAT64s) or this DNS server must use the ISP's DNS server  
as a forwarder. Note that there is text in the draft about DNS64  
forwarders. The latter is very common in the IPv4 world: CPEs tell  
local hosts that the CPE is the DNS server, but rather than talk to  
authoritative servers itself, the CPE simply forwards queries to the  
ISP's DNS server(s) and optionally caches the reults.

Note that getting fake AAAA records can be a problem in some  
circumstances, such as dual stack hosts. The SAS option is supposed to  
fix these issues but that obviously won't happen until both the server  
and the client, as well as any relays, implement it.

> As i mention earlier, it would be possible (and not very

The idea is that IPv6 CPEs could get the NAT64 prefix using DHCPv6  
along with other information (prefix delegation) that they learn from  
DHCPv6.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Jun 2008 15:17:29 +0200

> somewhere in the DNS resolution hierarchy.
imho, allowing the DNS64 to actually intercept dns messages can be a 
powereful deployment tool
I mean, i see a case for a nat64+DNS64 being a single box that is simply 
installed as the CPE and works, no additional changes needed.

imho the nat64 spec should not prevent this deployemnt approach

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 15:18:05 +0200

>>> that is always less than the binding lifetime in the NAT64?

At some point we were considering having a requirement for  
multihoming. That didn't seem realistic, so the next best thing is  
failing over to a different NAT64 if the current one becomes  
unreachable. The upper bits in fake AAAA records tell the hosts which  
NAT64 to use, so the TTL in those records imposes a minimum on the  
failover time. Other than that RFC 2766 requires a 0 (or 1) TTL to  
avoid the leaking of synthetic records. In the future when software  
like BIND can recognize the synthetic answer section option that  
should no longer be an issue. Then we can cache for a short time if we  
want quick failover or as long as we want if we don't want or can't do  
quick failover.

> query contained query type A.

Ok, we should clarify this in the draft, obviously when a client  
performs a query for one type the answer shouldn't come back with a  
query section for another type.

> host must consistently use the same NAT for different upper layer

Isn't this an explicit or implicit BEHAVE requirement? It would seem  
to me that this would break stuff like STUN if the STUN server is  
reached through one NAT and the intended correspondent through another.

>> we could add some flags to the sas option

I guess this depends on what we define the SAS option to be. IIRC the  
draft only talks about synthetic ADDRESSES so those can exist  
alongside the original CNAME record = no issues.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 15:24:04 +0200

> powereful deployment tool

Some people would call this a man-in-the-middle attack... Especially  
people who want to run DNSSEC.

> I mean, i see a case for a nat64+DNS64 being a single box that is  
> simply installed as the CPE and works, no additional changes needed.

Sure, that's fine. But then the hosts behind the CPE should receive  
configuration information from the CPE that tells them to use the CPE  
as their DNS so the CPE can perform the DNS64 function without problems.

If the users want to run a DNS resolver behind such a CPE that DNS  
resolver shouldn't have its DNS packet mangled.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Jun 2008 15:50:30 +0200

> people who want to run DNSSEC.
you need more than that to make dnssec work, so this point is irrelevant.

If you want dnssec to work, you need to implement dns64 fucntionality in 
the point the perfroms the dnssec validation, so this is completelly 
different dicusssion

> as their DNS so the CPE can perform the DNS64 function without problems.
sure that is one possibility, i have already said that i am ok with the 
dns64 functionality in the dns server is ok,
> resolver shouldn't have its DNS packet mangled.
What if your dns server do not support DNS64 but you want fast 
deployment of nat64?

Then having a dns64 fucntionality that intercepts dns messages allows 
you to deploy this.

The point being made here is that having a single box that you can buy 
and performs all the required functionality and works in all kind of 
differnet scenarios it a powerful deployment tool.

I agree that there are other configurations (like having it int he dns 
server) are better, but they simply don't conver some scenarios

My only point here is that we shouldn't preclude the possibilty of 
having a single box that supports other potential scenarios... i guess 
we would benefit from input from other people in the wg...

regards, marcelo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 23 Jun 2008 10:37:06 +0300

> lifetime? It would seem that the DNS64 TTL should be less

Yes. See RFC4787 §4.3 for instance.

Short binding lifetimes are a total killer for handhelds, due to battery 
drain. That being noted, in IPv6, there will probably still be firewalls with 
overly short lifetimes (because the broken firewall code will be ported from 
IPv4). A fortiori, in NAT64 cases, there will still be broken firewalls on 
the IPv4 part. As such, end nodes will continue to use a less-than-30 seconds 
UDP keepalive timer.

-- 
Rémi Denis-Courmont

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Jun 2008 10:03:07 +0200

On 22 jun 2008, at 15:50, marcelo bagnulo braun wrote:

>>> imho, allowing the DNS64 to actually intercept dns messages can be  
>>> a powereful deployment tool

>> Some people would call this a man-in-the-middle attack...  
>> Especially people who want to run DNSSEC.

> If you want dnssec to work, you need to implement dns64  
> fucntionality in the point the perfroms the dnssec validation, so  
> this is completelly different dicusssion

Well, not exactly. What if you have a site where you run a DNS server  
that wants to do DNSSEC? Maybe there are hosts in the site that have  
IPv4 connectivity through tunnels, or maybe they just have IPv6  
connectivity and no need to talk to the IPv6 world. This would work  
just fine until someone starts intercepting the packets for the DNS  
server doing the DNSSEC and inserting fake AAAA records.

In my opinion, the advantage of being able to deploy NAT64 without  
having to change DNS resolvers (which is what you get by intercepting  
all DNS packets and passing them through DNS64) is less important than  
the disadvantage of having unpredictable failures in things like DNSSEC.

> What if your dns server do not support DNS64 but you want fast  

Well obviously there will be a server that does DNS64 _somewhere_ if  
there is a NAT64 translator. If the local DNS server can't do DNS64  
and can't be made to forward queries to a DNS64 server, this means  
that the clients will have to talk to a non-local DNS64 server. I  
don't see how this is a big problem.

Also, if there is no local DNS64 capable system, who is going to do  
the DNS interception? Obviously you can't do that 5 hops away  
somewhere in the ISP network, this has to happen on a local network  
boundary, such as the site exit router. (In theory an ISP could do DNS  
interception for ALL traffic from ALL customers but that would be  
REALLY bad!)

> The point being made here is that having a single box that you can  
> buy and performs all the required functionality and works in all  
> kind of differnet scenarios it a powerful deployment tool.

Right, but if that box uses normal DNS provisioning mechanisms you  
don't need the interception. I.e., the box could do DHCPv6, RFC 5006  
(which clients will hopefully support by that time) and even DHCPv4 so  
the hosts will send their DNS requests to the box so it can do DNS64.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 14:57:22 +0200