Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt

[<[e-mail]>]

Cameron, 

Thanks again for reviewing the document:)

Replies inline:

> To that end, it is cited in our 464XLAT work
> http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the ideas
> have been included in 464XLAT Android code
> http://code.google.com/p/android-clat/

Very nice:-) 

> 1.  "the information learned enables applications and
>    hosts to perform local IPv6 address synthesis and on dual-stack
>    accesses avoid traversal through NAT64."
> 
> Can we generalize this further?  You say applications and host, but i am
> thinking home gateways as well. Perhaps say "enables software to perform
> local IPv6 address synthesis..." ?  You also use the term "node" in the draft,
> that may be a good fit.

We can, will think for better wording.
 
> 2.  "Furthermore, the host SHOULD cache the replies it
>    receives and honor TTLs."  Which TTL?  The TTL or ipv4only.arpa that is
> used for discovery?  Are you saying the discover of the PREF64 is bounded by
> a TTL?

Can be - the discovered Pref64::/n should remain valid at least for the duration of TTL that was used by network's DNS64 to synthetize the AAAA record. Hence node does not have to repeat discovery until the expiration of timer.

This can be clarified if you are ok with the idea.

(The TTL of ipv4only.arpa is probably longer than of Pref64::/n, and the TTL of Pref64::/n should not be longer than of ipv4only.arpa).

> 3.  The term NAT64 Prefix is used in this draft.  Would it be better to use the
> term Pref64 that is used in RFC 6146 and 6147?  Is NAT64 FQDN in section
> 3.1.1 the same thing?

Good point, the RFC6052 didn't use this (only NSP and WKP), but Pref64::/n is fine.

Similar term for the NAT64 FQDN term probably is not used in these other documents? I.e. other documents do not ask for naming the NAT64, while we do for DNSSEC reasons.

> 4.  Do you see any challenges for validating ULAs as the Pref64 with DNSsec?

Reverse lookup might be difficult, i.e. step 2 of 3.1.2, as there is no centrally managed ULA's yet... But I wonder if you could locally (in your DNS64) catch PTR queries for "ULA".ip6.arpa and return NAT64 FQDN as a response? If so, maybe it would work?

> 5. "The host then does an
>    A query of that hostname, which returns one or more A resource
>    records, which are the IPv4-facing IP addresses of that NAT64."
> What IPv4 address of the NAT64?  

External Internet facing IPv4 address of NAT64, any that is able to respond to ICMP Echo Req.

>RFC 6146 refers to IPv4 transport address,
> which i believe are commonly known as the "NAT pool"... do you mean those
>addresses?  

Well, not if NAT64 drops ICMP echo requests sent to those addresses or if it forwards them to other nodes...

I.e. preferably some other external IPv4 address NAT64 has. 

Please note that this address can be any IPv4 address, for example as of dedicated "ping server". But we thought it might be nice to keep the connectivity test "inside" NAT64 system.

> Also, i dont think any network operators
> wants you (or 30,000,000 cell phones) pinging their NAT box.  There are
> much cheaper boxes to ping.  This text needs to be pulled or completely
> reworked.  I suggest not treating the topic of connectivity checks at all.

After ping they all send data through the NAT box:) But individual devices should not send these ping tests too often - at most when learning Pref64::/n and not again until TTL timeout or reconnect.

But as written, connectivity test is not always required or useful: it may unnecessarily increase latency if done only at the time when user's transport sessions is already starting - in which case it might be wiser just to proceed with transport session and see if it makes through or not. 

Then again in some cases it might be useful, for example in the home gateway scenario you introduced: if the home gateway does not perform connectivity test, it would be synthesizing AAAA records for local hosts using discovered prefix without any knowledge if the prefix discovery was successful... If it was not, clients behind home gateway would be trying connections with broken IPv6 addresses..

So I'm not quite ready to remove the connectivity check, but we can try to fine tune it.

> 6.  3.1.1 #1 is not clear. Please elaborate on what that FQDN is supposed to
> be.

Any Fully Qualified Domain Name, the exact name should not matter much. E.g. "nat64.example.com". 

> 7.  Perhaps a state diagram for how DNSSEC validation works with
> PREF64 would help.

The numbered lists on 3.1.1 and 3.1.2 try to show it already.. and the DNSSEC procedures should be described in DNSSEC specifications. Hence I'm not sure I understand what diagram would you like to see?

Best regards,

	Teemu