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

[Cameron Byrne <[e-mail]>]

Resending to the list -- in line

On Jan 27, 2012 4:42 AM, <[e-mail]> wrote:
>
> 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).
>

Well, in the draft, the only guidance for ipv4only.arpa ttl is that it
not exceed 1 year... which does not help in this situation.

The draft would benefit from explicitly stating discovered pref64 ttl
= pref64 fqdn ttl. That way the ttl is completely in control of the
network operator.

> > 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.
>

How about nat64 node fqdn? that is descriptive and specific.  But
really, this concept is not acceptable as i will discuss below.

> > 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?
>

I can likely make that 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.
>

It does not need to be this way, right? What you really want is a
pairing of dns records, right? If that is what is needed, then lets
say that. I would much rather pair the pref64 fqdn with a dummy fqdn
for this purpose.  It is not acceptable to network operators to have a
name for an interface we do not want traffic to be destine to.

> >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.
>

Not nice. Cgn boxes are lots of asics / fpga / blah and relatively
weak control plane processors that explicitly rate limit icmp to avoid
control plane resource attacks. You cannot prescribe how this can be
treated, the existing text is not acceptable.  It may be acceptable if
you think NAT64 is a Linux box, but in may large deployments, it is a
very different case.

> > 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.
>

Icmp to the cgn and icmp via the cgn/nat64 are treated very
differently. The same can be said for core ip routers....and some
vendors think cgn is a blade on a core router ... those core routers
definately rate limit ICMP destine to the router itself.  This cannot
be changed.


> 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.
>

Yes.

> 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..
>

Fine. But the method described is not acceptable.

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

Ack

> > 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?
>

Since I was fuzzy on the taxonomy, the pieces were not fitting.

Net net, this draft, IMHO, needs to define a procedure based on fqdn
and optional connectivity checks.

And.

It is not acceptable to expect any interface on the nat64 node to have
an fqdn or to send icmp connectivity checks to the nat64 node.  The
pref64 may have an fqdn, that does make sense to me.

This draft would benefit from describing "what" needs to be done, not
"how" it will be done.

Cb

> Best regards,
>
>        Teemu