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

From: [email-masked]
Date: Wed, 25 Jan 2012 13:15:13 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name
	Author(s)       : Teemu Savolainen
                          Jouni Korhonen
                          Dan Wing
	Filename        : draft-ietf-behave-nat64-discovery-heuristic-05.txt
	Pages           : 14
	Date            : 2012-01-25

   This document describes a method for detecting presence of DNS64 and
   for learning IPv6 prefix used for protocol translation on an access
   network without explicit support from the access network.  The method
   depends on existence of a well-known IPv4-only domain name
   "ipv4only.arpa".  The information learned enables applications and
   hosts to perform local IPv6 address synthesis and on dual-stack
   accesses avoid traversal through NAT64.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-05.txt

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 17:15:51 +0000

Ok, will check the TTL, but I though the obvious would have been to use the shorter of the two: A record TTL or remaining Pref64::/n lifetime (maybe I'm making dangerous assumption again when assuming Pref64::/n HAS a lifetime:)

For connectivity check I would like to hear other opinions as well. I guess we have on the table:
- no check documented
- optional for vendor specific server
- optional for operator hosted server (learnt via A record of NAT64 FQDN)

Teemu

----- Original message -----
>
> On Jan 30, 2012 4:52 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Cameron,
> >
> > > 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.
> >
> > The operator is in control of TTL used in synthetic AAAA records
> operator's DNS64 creates, or am I mistaken? And that TTL does not have
> to equal to related A record TTL. I.e. even if ipv4only.arpa would have
> 1 year TTL, the DNS64 that synthesizes IPv6 addresses can use much lower
> TTL, hence cause nodes to have much shorter TTL for the discovered
> prefix.
> >
>
> I believe you are mistaken. Rfc 6147 says the original ttl is passed on,
> from the best of my reading.
>
> > If the host performs PTR query and forward AAAA query as currently
> described in DNSSEC section, then I guess the TTL used by node could be
> the NAT64 FQDN TTL?
> >
> > > 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.
> > >
> > > 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.
> > >
> > > Net net, this draft, IMHO, needs to define a procedure based on fqdn
> and
> > > optional connectivity checks.
> >
> > What we are looking here is to enable connectivity checks without
> mandating developers to host connectivity check servers and to keep
> connectivity checks as local as possible.
> >
>
> Pushing the burden to the operator is not acceptable without consent. I
> suppose having that fqdn implies consent
>
> > > 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.
> >
> > The IPv4 address found via described procedure does not really have to
> point to NAT64, it can point to any IPv4 address chosen by the owner of
> NAT64's FQDN, or be non-existent... I.e. you could disable connectivity
> checks by not having A record (which is the case anyway currently as
> there's no standard way for host to learn NAT64's FQDN, which does not
> necessarily even exist), or you could point the checks to separate
> server.
> >
> > So.. would it help if we would move all of the A record stuff from
> DNSSEC section to the optional connectivity check section, and describe
> there that network operator may help nodes on connectivity checks by
> having A record for the NAT64 FQDN that points to somewhere (be that
> NAT64 itself, or some dedicated server)?
> >
>
> Yes. That would help. But, pinging the cgn is really a recipe for
> disaster that I would rather not see documented or suggested without
> caution.
>
>
> > Best regards,
> >
> > Teemu
>
>