Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

From: Dave Thaler <[email-masked]>
Date: Sat, 2 Jun 2012 01:07:24 +0000

This email initiates a two-week Working Group Last Call on 
draft-ietf-behave-nat64-discovery-heuristic-09, to conclude
Friday June 15th.   Hopefully that will give some time before
our next interim meeting to review the comments and
have proposed resolutions ready to discuss at the
June 21st interim meeting.

We need at least 5 reviewers to comment on the doc 
(even if just saying "loos good").

-Dave Thaler

---

From: Aaron Yi DING <[email-masked]>
Date: Mon, 11 Jun 2012 16:05:56 +0300

Hello,

A few comments on this WG I-D, 
draft-ietf-behave-nat64-discovery-heuristic-09

1) Section 3 the first paragraph, "The node MAY also need to perform DNS 
query for the A record of the well-know name in order to learn what is 
the IPv4 address of the well-known name and if the A record even exists".

The phrase MAY is bit unclear to me, because in Section 7, there is such 
description, "A node SHOULD implement validating DNSSEC resolver for 
validating the A response of the well-known name query."

It is unnecessary to perform redundant A record query for WKP; but for 
NSP, such query is probably required. So for clarity, would it be good 
to state as such:

"The node MAY also need to perform DNS query for the A record of the 
well-know name in order to learn what is the IPv4 address of the 
well-known name and if the A record even exists (in the case of 
identifying Network-Specific Prefix, the node SHOULD perform a secure 
DNS A query to validate the A record received".

2) Section 3 the fifth paragraph,  "In case another instance of the 
value is found inside the IPv6, the node shall repeat the search with 
another IPv4 address, if possible."

It's good to add a few words concerning what SHOULD a node do if all of 
the IPv4 addresses have been tried but failed (some other instances are 
found in the IPv6).

3) Section 3.1.2, the description is very concise and clear here. 
However, one simple figure illustrating the message flow and major 
components involved in such secure learning will improve the overall 
clarity.

4) Also in Section 3.1.2, I suppose the network Entity responding to 
step 2 and step 4 could be DNS64 which is controlled by the operator, 
but in the text, no text referring to this detail. This comment is bond 
to the previous comment 3, a simple figure might achieve more  v.s. 
awful lots of text.

5) Regarding to multi-interfaced, one short additional section might be 
helpful to clarify potential issues.

As described in Section 1, "if a node is multi-interfaced. In such cases 
nodes may choose to prefer IPv4 or alternative network interface in 
order to avoid traversal through protocol translators."
for the scenario where multiple NAT64/DNS64 are deployed on different 
accesses, how to utilize the learned Pref64 selectively and properly is 
a general problem. Following the ideas in RFC 6418,  the synthesized 
AAAA record and the learned Pref64 are guaranteed to be valid only on 
the network from which such knowledge is obtained. So the 
multi-interfaced hosts SHOULD distinguish the learned Pref64 and its 
usage (e.g. performing local synthesis) from different networks in order 
to avoid potential conflicts.

a  brief section like Multi-interfaced Host Considerations

In general, this draft is well written. The security and connectivity 
sections had significant improvement from the previous versions.

-- Aaron

On 02/06/12 04:07, Dave Thaler wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Jun 2012 10:51:25 -0400

Dear colleagues,

> draft-ietf-behave-nat64-discovery-heuristic-09, to conclude

I read this draft.

First, as I've said before for the record, I think this is a bad way
to do all of this.  I accept that it's the way people are doing it
anyway, so I think it is better to write it down.  With that proviso,
I think this document is ready to be published.  It's still a bad way
to do it.

At the end of section 3:

        […]it SHALL repeat the discovery
   process when one third of the Time-To-Live of the Well-Known Name's
   synthetic AAAA DNS response is remaining.

This should probably say instead "when one third (or less) of the
original Time To Live…."  The "or less" avoids having to time this
precisely and the "original" is to make clear what is being compared
against.  These are both nits.

I think this has been pointed out before: section 3.1.1 depends either
on the reverse tree in which the NAT64 exists having a DS at the
parent or else a locally-configured trust anchor.  Should this be
noted?  (Maybe it isn't necessary.  I probably should, but don't, know
whether all RIRs are signing their reverse trees yet.  I know ARIN and
RIPE do.)

I think either section 3.1.2 or the Security Considerations should
state explicitly that it is impossible to use this heuristic and
DNSSEC in an unknown network, which effectively means that DNSSEC and
NAT64 cannot be used in coffee shops.  (It just occurred to me this
minute that there might be some sort of tricky DLV-style thing one
could do, but I haven't thought about it seriously.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 11:02:15 +0000

Hi Andrew,

Thank you for your comments, responses inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Andrew Sullivan
> Sent: 11. kesäkuuta 2012 17:51
> To: [email-masked]
> Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09
> 
> Dear colleagues,
> 
> First, as I've said before for the record, I think this is a bad way to do all of this.
> I accept that it's the way people are doing it anyway, so I think it is better to
> write it down.  With that proviso, I think this document is ready to be
> published.  It's still a bad way to do it.
> 
> At the end of section 3:
> 
> This should probably say instead "when one third (or less) of the original Time
> To Live…."  The "or less" avoids having to time this precisely and the "original"
> is to make clear what is being compared against.  These are both nits.

Good point and I agree, will fix.

> I think this has been pointed out before: section 3.1.1 depends either on the
> reverse tree in which the NAT64 exists having a DS at the parent or else a
> locally-configured trust anchor.  Should this be noted?  (Maybe it isn't
> necessary.  I probably should, but don't, know whether all RIRs are signing their
> reverse trees yet.  I know ARIN and RIPE do.)

I thought reverse tree does not require signing. The node performs reverse query at section 3.1.2 step 2 and this should result in NAT64 FQDN that is in node's list of trusted domains (step 3), and after that node sends AAAA query and verifies response to that. If the (attacker's malicious response) PTR record has name of some non-trusted domain, the DNSSEC capable node can reject the response.

> I think either section 3.1.2 or the Security Considerations should state explicitly
> that it is impossible to use this heuristic and DNSSEC in an unknown network,
> which effectively means that DNSSEC and
> NAT64 cannot be used in coffee shops.  (It just occurred to me this minute that
> there might be some sort of tricky DLV-style thing one could do, but I haven't
> thought about it seriously.)

Without this heuristic in play...
1) IPv6-only coffee shop could not use NAT64 and DNSSEC together well, as all synthetic AAAA records would be dropped by host (=no connectivity to IPv4-only destinations)
2) Dual-stack coffee shop would work with DNSSEC as the host would drop all synthetic AAAA records (hence connections to IPv4-only destinations would go via IPv4)

Now, with the heuristic..
1) IPv6-only coffee shop could not support NAT64 and DNSSEC together, as the heuristics could not determine Pref64::/n reliably (=no connectivity to IPv4-only destinations as local synthesis impossible)
2) Dual-stack coffee shop would work with DNSSEC, even if host could not determine Pref64::/n (connections to IPv4-only destinations would go via IPv4)

So heuristics does not really change the picture, right? Only thing that changes is that instead of failing to validate synthetic AAAA records from DNS64, the host fails to synthesize AAAA records by itself?

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 11:32:04 +0000

Hi Aaron,

Thank you for your review, responses inline:

> Of ext Aaron Yi DING
> Sent: 11. kesäkuuta 2012 16:06
> To: [email-masked]
> Cc: Dave Thaler
> query for the A record of the well-know name in order to learn what is the IPv4
> address of the well-known name and if the A record even exists".
> 

The MAY refers to host making DNS A query at first place (host MAY omit A query as the well-known name will have well-known IPv4 address). But if host makes DNS A query, it SHOULD verify the response.

> It is unnecessary to perform redundant A record query for WKP; but for NSP,
> such query is probably required. 

I think that for sake of simplicity we do not need to differentiate procedure between WKP and NSP (but I ack that a host could first do AAAA query and in case of non-WKP AAAA reply, then make A query to find out what is the address host should search for:)

>So for clarity, would it be good to state as
> such:
>
> "The node MAY also need to perform DNS query for the A record of the well-
> know name in order to learn what is the IPv4 address of the well-known name
> and if the A record even exists (in the case of identifying Network-Specific
> Prefix, the node SHOULD perform a secure DNS A query to validate the A
> record received".

This is ok for me - to normatively say SHOULD here in addition (or maybe perhaps instead) of just stating that in Security Considerations. But as said I'd prefer not differentiate procedures between NSP and WKP, so maybe something like:
"The node MAY also need to perform DNS query for the A resource record of the well-known name in order to learn what is the IPv4 address of the well-known name and if the A resource record even exists (see also Section 6 Exit Strategy). The node SHOULD use a secure channel for DNS A resource record query or validate the DNS A resource record response with DNSSEC."

> 2) Section 3 the fifth paragraph,  "In case another instance of the value is found
> inside the IPv6, the node shall repeat the search with another IPv4 address, if
> possible."
> 
> It's good to add a few words concerning what SHOULD a node do if all of the
> IPv4 addresses have been tried but failed (some other instances are found in
> the IPv6).

True.. but what that might be?-)  Maybe:
"The node should ensure a 32-bit IPv4 address value is present only once in an IPv6 address.  In case another instance of the value is found inside the IPv6, the node shall repeat the search with another IPv4 address, if possible. In case the Pref64::/n cannot be unambiguously determined from an IPv6 address, the node MUST fail the Pref64::/n discovery procedure for that IPv6 address." ?

> components involved in such secure learning will improve the overall clarity.

This would perhaps mean new section like "3.1.3 Example message flow"? Let me consider it - would others wish to see an illustrative figure as well?

> 4) Also in Section 3.1.2, I suppose the network Entity responding to step 2 and
> step 4 could be DNS64 which is controlled by the operator, but in the text, no
> text referring to this detail. This comment is bond to the previous comment 3, a
> simple figure might achieve more  v.s.
> awful lots of text.

It does not have to be the DNS64, in fact. The PTR query should work with any recursive DNS server host has access to (even those from other interfaces) and also the AAAA query for NAT64 FQDN can be sent to any recursive DNS server. Of course the host can send queries to the DNS64 (and for sake of clarity I think that would be the entity in the possible future illustrative figure).

> 5) Regarding to multi-interfaced, one short additional section might be helpful
> to clarify potential issues.
> 
> As described in Section 1, "if a node is multi-interfaced. In such cases nodes
> may choose to prefer IPv4 or alternative network interface in order to avoid
> traversal through protocol translators."
> accesses, how to utilize the learned Pref64 selectively and properly is a general
> problem. Following the ideas in RFC 6418,  the synthesized AAAA record and
> the learned Pref64 are guaranteed to be valid only on the network from which
> such knowledge is obtained. So the multi-interfaced hosts SHOULD distinguish
> the learned Pref64 and its usage (e.g. performing local synthesis) from different
> networks in order to avoid potential conflicts.
> 

On this I have to disagree. The multi-interface problems, considerations, and solutions should be taken care by MIF WG, e.g. in documents such as the RFC6418 you referred and draft-ietf-mif-dns-server-selection-09 (this problem is described there in section 2.2). 

> In general, this draft is well written. The security and connectivity sections had
> significant improvement from the previous versions.

Thank you,

Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2012 10:06:10 -0400

Hi,

> I thought reverse tree does not require signing. The node performs reverse query at section 3.1.2 step 2 and this should result in NAT64 FQDN that is in node's list of trusted domains (step 3), and…

That's how it's written just now, yes.  The difficulty I see is that
the decision tree includes step 2, "RDATA of PTR not on trusted list,
ask user."  The user has, in that context, absolutely no way of making
any safe decision.  I'd be surprised if the security directorate
didn't complain about this.

Also, I just realized that step 2 is written as though the result of
the PTR query will always be one RR.  That need not be the case.
There could be more than one (or there could be a CNAME or DNAME chain
there).  Therefore, I think step 2 of 3.1.2 should say this:

   2.  Send DNS PTR query for the IPv6 address of the translator (for
       "ipv6.arpa"), using the Pref64::/n from the step 1 and zeroes for
       the elements after the actual prefix length.  CNAME and DNAME
       results should be followed according to the rules in [RFC1034],
       [RFC1035], and [draft-ietf-dnsext-rfc2672bis-dname]*.  The
       ultimate response will include one or more NAT64 FQDNs.

* note that that's in the RFC Ed queue.  We're waiting for some
response from an AD and then it will come out.

Or something similar.  I should have caught this before.  My apologies.

> So heuristics does not really change the picture, right?

Right.  It's ok with me if it just says, "This does not change the
picture for 'coffee shop' ad hoc network use," or something like that
too.  The point is really just that DNS64/NAT64 is never going to be
an option wherever you have a lot of people who don't trust the
network trying to use it, and also trying to use DNSSEC.  If DANE/TLSA
takes off, this will be a problem.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Aaron Yi DING <[email-masked]>
Date: Tue, 12 Jun 2012 20:17:24 +0300

Hi Teemu,

> "The node MAY also need to perform DNS query for the A resource record of the well-known name in order to learn what is the IPv4 address of the well-known name and if the A resource record even exi…

The description above looks good.

> True.. but what that might be?-) Maybe: "The node should ensure a 
> 32-bit IPv4 address value is present only once in an IPv6 address. In 
> case another instance of the value is found inside the IPv6, the node 
> shall repeat the search with another IPv4 address, if possible. In 
> case the Pref64::/n cannot be unambiguously determined from an IPv6 
> address, the node MUST fail the Pref64::/n discovery procedure for 
> that IPv6 address." ?

I'm fine with this one.

> This would perhaps mean new section like "3.1.3 Example message flow"? 
> Let me consider it - would others wish to see an illustrative figure 
> as well? 

Such illustrative figure for secure learning is my personal opinion. 
Let's see how others feel about it.

> On this I have to disagree. The multi-interface problems, considerations, and solutions should be taken care by MIF WG, e.g. in documents such as the RFC6418 you referred and draft-ietf-mif-dns-ser…

Make sense. I agree with you this mif related discussion isn't suitable 
for this document.

Cheers,
Aaron

---

From: <[email-masked]>
Date: Mon, 18 Jun 2012 18:59:06 +0000

Hi Andrew,

> Sent: 12. kesäkuuta 2012 17:06
> To: [email-masked]
> > I thought reverse tree does not require signing. The node performs reverse
> query at section 3.1.2 step 2 and this should result in NAT64 FQDN that is in
> node's list of trusted domains (step 3), and after that node sends AAAA query
> and verifies response to that. If the (attacker's malicious response) PTR record
> has name of some non-trusted domain, the DNSSEC capable node can reject
> the response.
> >
> 
> That's how it's written just now, yes.  The difficulty I see is that the decision
> tree includes step 2, "RDATA of PTR not on trusted list, ask user."  The user
> has, in that context, absolutely no way of making any safe decision.  I'd be
> surprised if the security directorate didn't complain about this.

That's something similar to the case with web pages with expired certificates.. How can you manage without asking user ok? Unless host just simply fails the prefix discovery... and perhaps display that fact in some "problem solving wizard" as cause for prefix discovery failure?
 
> Also, I just realized that step 2 is written as though the result of the PTR query
> will always be one RR.  That need not be the case.
> * note that that's in the RFC Ed queue.  We're waiting for some response from
> an AD and then it will come out.

This is fine, thank you. Tthen in step 3 the node should compare all the NAT64 FQDNs received to the list of trusted domains (and pick one that has match).

> Or something similar.  I should have caught this before.  My apologies.

No problem, especially as we are still in WG process:)

> Right.  It's ok with me if it just says, "This does not change the picture for
> 'coffee shop' ad hoc network use," or something like that too.  The point is
> really just that DNS64/NAT64 is never going to be an option wherever you
> have a lot of people who don't trust the network trying to use it, and also
> trying to use DNSSEC.  If DANE/TLSA takes off, this will be a problem.

Ok, I'll attempt to write that issue down.

Best regards,

	Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jun 2012 16:02:32 -0400

On Mon, Jun 18, 2012 at 06:59:06PM +0000, [email-masked] wrote:
> That's something similar to the case with web pages with expired
> certificates.

Yep.  The security guys, in my experience, jump up and down about
this.  It might be worth asking someone for an early review.  I can't
see what you're going to do except ask the user, other than
immediately fail; and in that case, of course, you're going to have to
give the user an interface anyway.  I'd ask for a secdir review
specifically of this, though, because it's the sort of thing I know
people have strong opinions about.

> This is fine, thank you. Tthen in step 3 the node should compare all the NAT64 FQDNs received to the list of trusted domains (and pick one that has match).

Right.  And, hurray, http://tools.ietf.org/html/rfc6672 is out.  So
that's your reference now.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Jun 2012 23:57:12 +0000

My full comments and proposed editorial changes are in 
http://research.microsoft.com/~dthaler/draft-ietf-behave-nat64-discovery-heuristic-09.pdf

A brief summary of the main technical comments:

1) I didn't follow why an A record query is needed or useful.

2) Guidance on TTL is lacking.  How long is "long"? 

3) Need to update text on how often to repeat the check in the success case.
Saying it MUST be one third the TTL seems overly strict and suboptimal given
that the TTL itself could be short (like 9 seconds) or long (like 9 months) and no 
guidance on that is given.   Why not a specific number of seconds/minutes before
expiry, rather than a fraction of the TTL?

4) The text in 3.1.2 on verifying the address matches seems wrong (or else
I'm missing something), since querying for ipv4only.com will give Pref64::WKA::0
whereas querying for the NAT64 FQDN will give (per 3.1.1 bullet 2) Pref63::0.
Those won't match.   I'm guessing 3.1.1 bullet 2 is probably in error.

-Dave

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dave Thaler
> Sent: Friday, June 1, 2012 6:07 PM
> To: [email-masked]
> Subject: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09
> 
> This email initiates a two-week Working Group Last Call on draft-ietf-behave-
> nat64-discovery-heuristic-09, to conclude
> our next interim meeting to review the comments and have proposed
> resolutions ready to discuss at the June 21st interim meeting.
> 
> We need at least 5 reviewers to comment on the doc (even if just saying
> "loos good").
> 
> -Dave Thaler
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Tue, 19 Jun 2012 00:00:09 +0000

So far I've seen 3 reviews:
* Andrew Sullivan
* Aaron Yi DING
* Dave Thaler

We need at least 5 reviews on this document.   Can we get two more volunteers?
Maybe Simon and/or Marc P.-H.?  Anyone else?

-Dave

---

From: <[email-masked]>
Date: Tue, 19 Jun 2012 08:56:52 +0000

Hi Dave,

Thank you for your review. The proposed changes in PDF look fine and will be incorporated.

Responses inline for your questions:

> Of ext Dave Thaler
> Sent: 19. kesäkuuta 2012 02:57
> To: [email-masked]
> Cc: [email-masked]

If a host needs to know whether the well-known name service is up and running (no A record would explain lack of synthetic AAAA record). 

If a host has not hard-coded the well-known IPv4 address and the host wants to learn it on the go.

> 2) Guidance on TTL is lacking.  How long is "long"?

In the past the document said "a year", but the feedback was that recursive DNS servers will cap it anyway to something shorter. Hence I do not have better idea of what would be exact value. A month? I also noticed now that the section 4 is not updated according to latest idea of permanent IANA allocation for well-known IPv4 address.

Hence maybe this would be better section 4:
--
4.  Operational Considerations for Hosting the IPv4-Only Well-Known Name

   The authoritative name server for the well-known name shall have DNS
   record Time-To-Live (TTL) set to at least 60 minutes in order to improve
   effectiveness of DNS caching.  The exact TTL value will be determined
   and tuned based on operational experiences. 

   The domain serving the well-known name must be signed with DNSSEC.
   See also Security Considerations section.
--

> expiry, rather than a fraction of the TTL?

We could say 10 minutes before expiry, and then on the TTL place requirement  for minimum TTL (I drew minimum TTL of 60 minutes out from thin air). Would it be better?

> 4) The text in 3.1.2 on verifying the address matches seems wrong (or else I'm
> missing something), since querying for ipv4only.com will give Pref64::WKA::0

Hm.. The idea is that in the step 1 host indeed gets synthetic address like Pref64::WKA::0, but in the step 2 the host omits the WKA from the address it queries and just asks for Pref64::0 (i.e. just prefix). 

The intent of this has been to allow changing WKA; NAT64 operator would need to just configure entry for Pref64::0 and whatever the WKA happens to be, the name would be found this way. 

Of course as we now seem to be heading for eternally fixed WKA, we could mandate step 2 of 3.1.1 to be like:
--
   2.  Each NAT64 FQDN MUST have one or more DNS AAAA resource records
       with each IPv6 address consisting of Pref64::/n and WKA.
--

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Tue, 19 Jun 2012 11:30:07 +0000

Hi Andrew,

> Yep.  The security guys, in my experience, jump up and down about this.  It
> might be worth asking someone for an early review.  I can't see what you're
> going to do except ask the user, other than immediately fail; and in that case,
> of course, you're going to have to give the user an interface anyway.  I'd ask
> for a secdir review specifically of this, though, because it's the sort of thing I
> know people have strong opinions about.

In silent fail case the user can still access all destinations that do not require going through NAT64.. Any idea of who to ask? I don't personally know any currently active IETF security area expert..
 
> Right.  And, hurray, http://tools.ietf.org/html/rfc6672 is out.  So that's your
> reference now.

Will refer:)

	Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Jun 2012 09:16:46 -0400

> In silent fail case the user can still access all destinations that do not require going through NAT64.. Any idea of who to ask? I don't personally know any currently active IETF security area expe…

Probably best just to ask the relevant ADs for a pointer.
[email-masked] oughta work, I think?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 19 Jun 2012 06:59:07 -0700

On 06/18/2012 05:00 PM, Dave Thaler wrote:
> So far I've seen 3 reviews: * Andrew Sullivan * Aaron Yi DING * Dave
> Thaler
> 
> We need at least 5 reviews on this document.   Can we get two more
> volunteers? Maybe Simon and/or Marc P.-H.?  Anyone else?

I am not a DNS or IPv6 specialist, but I'll do my best.  Expect my review
before the 21st.

> 
> -Dave
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Dave Thaler Sent: Friday,
>> June 1, 2012 6:07 PM To: [email-masked] Subject: [BEHAVE] Last call:
>> draft-ietf-behave- nat64-discovery-heuristic-09, to conclude Friday June
>> 15th.   Hopefully that will give some time before our next interim
>> meeting to review the comments and have proposed resolutions ready to
>> discuss at the June 21st interim meeting.
>> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Dave Thaler <[email-masked]>
Date: Tue, 19 Jun 2012 19:19:39 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2012 1:57 AM
> To: Dave Thaler; [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-
> 09
> 
> Hi Dave,
> 
> > Behalf Of ext Dave Thaler
> > Subject: Re: [BEHAVE] Last call:
> > http://research.microsoft.com/~dthaler/draft-ietf-behave-nat64-discove
> > ry-
> > heuristic-09.pdf
> >
> If a host needs to know whether the well-known name service is up and
> running (no A record would explain lack of synthetic AAAA record).

I don't see any discussion of this in the doc.   Either the A record query
should be removed or else it should be explained how it's used as part of
the algorithm.
 
> If a host has not hard-coded the well-known IPv4 address and the host wants

Why would a host not hard-code it/them?
 
> In the past the document said "a year", but the feedback was that recursive
> DNS servers will cap it anyway to something shorter. Hence I do not have
> better idea of what would be exact value. A month? I also noticed now that
> the section 4 is not updated according to latest idea of permanent IANA
> allocation for well-known IPv4 address.
> 

That's much better yes.
 
> > Saying it MUST be one third the TTL seems overly strict and suboptimal
> > given that the TTL itself could be short (like 9 seconds) or long
> > (like 9 months) and no
> We could say 10 minutes before expiry, and then on the TTL place
> requirement  for minimum TTL (I drew minimum TTL of 60 minutes out from
> thin air). Would it be better?

Much better.   Though 10 minutes seems long.   It just has to be long
enough to have a very high probability of succeeding before expiry
(taking into account, loss, retries, etc.).

> > 4) The text in 3.1.2 on verifying the address matches seems wrong (or
> > else I'm missing something), since querying for ipv4only.com will give
> > Pref64::WKA::0 whereas querying for the NAT64 FQDN will give (per 3.1.1
> bullet 2) Pref63::0.
> Hm.. The idea is that in the step 1 host indeed gets synthetic address like
> Pref64::WKA::0, but in the step 2 the host omits the WKA from the address it
> queries and just asks for Pref64::0 (i.e. just prefix).
> 
> The intent of this has been to allow changing WKA; NAT64 operator would
> need to just configure entry for Pref64::0 and whatever the WKA happens to
> be, the name would be found this way.
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Jun 2012 10:20:28 -0400

> Maybe Simon and/or Marc P.-H.?  Anyone else?

Here's my review...

Major
-----

>    A node requiring information about presence of NAT64 and the
>    Pref64::/n used for protocol translation SHALL send a DNS query for
>    AAAA records of a well-known IPv4-only fully qualified domain name:
>    "ipv4only.arpa".

Why is there a need for a well-known IPv4-only domain name with a 
well-known IPv4 address? Why can't this stuff be 
implementation-specific, as suggested in section 3.3?

>    The well-known name needs to map to at least two different global
>    IPv4 addresses.  The addresses are to be taken from 192.0.0.0/24
>    address block.

Same preoccupation here. Why not leave this up to implementations?

>    In the case of more than one Pref64::/n were present in the DNS
>    response: a node SHOULD use all of them when determining whether
>    other received IPv6 addresses are synthetic.  However, for selecting
>    Pref64::/n for the local IPv6 address synthesis node MUST use the
>    following prioritization order, of which purpose is to avoid use of
>    Pref64::/n containing suffixes reserved for the future [RFC6052]:
>
>    1.  Use NSP having /96 prefix
>
>    2.  Use WKP prefix
>
>    3.  Use longest available NSP prefix

I would assume that the reason for the ISP's use of multiple DNS64 
prefixes would be DNS-based NAT64 load balancing. The above 
prioritization breaks that. In any case, it would be best if the host 
would try to mimic the DNS64 behaviour as much as possible so that the 
resulting NAT64 traffic patterns are not affected. That is, instead of 
picking one prefix and synthesizing a single AAAA record, synthesize a 
full AAAA RRset using all prefixes, and randomize the order of records.

>    3.  Each Pref64::/n MUST HAVE PTR record that points to corresponding
>        NAT64 FQDN.
>
>    4.  Sign the NAT64 FQDNs' AAAA and A records with DNSSEC.

Wouldn't it be better to sign the PTR record and have the host verify 
that signature instead of checking against a list of trusted domains?

>    The connectivity check protocol used with connectivity check servers
>    pointed by NAT64 FQDN's A records is ICMPv6 [RFC4443].

I understand that vendor checks are preferred over ICMPv6, but I still 
think recommending ICMPv6 at all is wrong. ICMP can fail for a myriad of 
reasons, including ICMP echo reply rate limiting. It is just not a good 
protocol to recommend as a connectivity check. If you do want to 
recommend one, I would suggest STUN. I would also be fine with not 
recommending one and only discussing vendor-specific checks.

Minor
-----

>    The knowledge of IPv6 address synthesis taking place may also be
>    useful if DNS64 and NAT64 are present in dual-stack enabled access
>    networks or if a node is multi-interfaced [RFC6418].  In such cases
>    order to avoid traversal through protocol translators.

I would s/in order to avoid traversal through protocol translators// 
since there's no guarantee that IPv4 will not be NATed.

>    It is important to notice that use of this approach will not result
>    in as robust, secure, and good behaving system as an all-IPv6 system
>    would be.  Hence it is highly recommended to upgrade nodes'
>    destinations to IPv6 and utilize the described method only as a
>    short-term solution.

Suggestion: s/short-term/transition/

>    A DNS reply with one or more non-empty AAAA records indicates that
>    the access network is utilizing IPv6 address synthesis.

It would be nice to note that DNS services that do NXRRSET hijacking 
will break this assumption.

>    The node should ensure a 32-bit IPv4 address value is present only
>    once in an IPv6 address.  In case another instance of the value is
>    found inside the IPv6, the node shall repeat the search with another
>    IPv4 address, if possible.

s/should/SHOULD/ ?
s/shall/SHALL/ ?

Why not MUST?

What other IPv4 address? Isn't there a single well-known IPv4 address?

>    3.  Each Pref64::/n MUST HAVE PTR record that points to corresponding
>        NAT64 FQDN.

This needs to be made more precise. Prefixes can't have PTR records 
(yet, there's a draft about that). Actually, I should be even more 
precise, since any domain name can "have" a PTR record. So, something 
like "For each Pref64::/n, there MUST be a PTR record for the domain 
name in the ip6.arpa tree corresponding to the Pref64:: address. That 
PTR record's value MUST be the corresponding NAT64 FQDN."

>    The node SHOULD use vendor specific connectivity check server and a
>    protocol of vendor's choice, but if that is not possible a node MAY
>    do a PTR query of the Pref64::/n that may return a hostname.

Again, prefixes do not have associated PTR records. Addresses do. This 
text needs to be made more precise.

>    A node SHOULD implement configuration knob for disabling the
>    Pref64::/n discovery feature.

Why not s/SHOULD/MUST/ ?

Nits
----

> Abstract
>
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
                  ^the
>    network.  The method depends on existence of a well-known IPv4-only
                                     ^the
>    domain name "ipv4only.arpa".  The information learned enables nodes
>    to perform local IPv6 address synthesis and to potentially avoid
>    traversal through NAT64 on dual-stack accesses and multi-interface
s/traversal through//
>    deployments.

>    The node SHOULD use vendor specific connectivity check server and a
>    protocol of vendor's choice

Here and in other spots in the document, s/vendor/implementation/.

Implementations don't necessarily involve a "vendor", particularly 
open-source ones.

>    The domain serving the well-known name must be signed with DNSSEC.

s/must/MUST/

>    The IPv4 addresses for the well-known name must not be non-global

s/must not be non-global/MUST be global/

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jun 2012 10:38:26 -0400

> implementation-specific, as suggested in section 3.3?

The reason I suppose the well-known name is because it will make
caches more efficient.  If it's a well-known name and everyone uses
it, then every application is looking for the same name, meaning that
for a host doing multiple things behind a DNS64 the answer will most
of the time be cached.  Otherwise, every application generates a bunch
of housekeeping queries, and the global DNS has to do more work.

> Wouldn't it be better to sign the PTR record and have the host
> verify that signature instead of checking against a list of trusted
> domains?

Yes, but it won't work, because the delegation from the reverse tree
won't be able to be signed because the response is always local. 

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Jun 2012 11:32:13 -0400

> of housekeeping queries, and the global DNS has to do more work.

I really doubt it would make a difference in the grand scheme of things.

> won't be able to be signed because the response is always local.

...for the well-known name, which has addresses in 192.0.0.0. 
Implementation-specific names would not have this problem.

Anyway, wouldn't this be a good reason not to use 192.0.0.0 and instead 
use a "regular" address that would be looked up normally? I mean, using 
DNSSEC all the way seems much better than the "list of trusted domains" 
hack.

Simon

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 16:44:00 +0000

Simon,

A host implementation could very well use vendor specific well-known name as well and ignore this draft - it would work perfectly. However, for cases where vendor specific name is not available (maybe not all application writers, for example, do not have facilities to host their own names), the well-known name is useful.

I don't see how DNSSEC protecting PTR query would help in the "trusted domains" question. All that host could learn is that PTR query can be verified to be owned by badguys.hotspot.example.com, right?

Best regards,

Teemu

________________________________________
From: [email-masked] [[email-masked]] on behalf of ext Simon Perreault [[email-masked]]
Sent: Wednesday, June 20, 2012 6:32 PM
To: [email-masked]
Subject: Re: [BEHAVE] Last call:        draft-ietf-behave-nat64-discovery-heuristic-09

Simon

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 17:17:59 +0000

Inline, again:

> From: ext Dave Thaler [mailto:[email-masked]]
> Sent: 19. kesäkuuta 2012 22:20
> To: Savolainen Teemu (Nokia-NRC/Tampere); draft-ietf-behave-nat64-
> [email-masked]
> Cc: [email-masked]

> should be removed or else it should be explained how it's used as part of the
> algorithm.

The beginning of section 3 tries to say this:
--
The node MAY also need to perform DNS query for the
A record of the well-known name in order to learn what is the IPv4
address of the well-known name and if the A record even exists
--
but I admit this is weak text. We wanted to avoid A queries all the time...

Let me think:

If a node gets a positive response to an AAAA query for the well-known name, the host learns presence of DNS64. Lack of AAAA response could mean either no DNS64 or no A record for the well-known name.

Perhaps we could say that, lacking positive response to AAAA query, node could do at a new 3.1.2 step "1.5" an A query to see if the A record exist. If A record is there, then network does not have DNS64 (and in case of IPv6-only network, does not provide translation services).

> Why would a host not hard-code it/them?

To allow flexibility for the future:) But perhaps this flexibility could be a problem.. and we could state that hosts can hard code the address.

> > requirement  for minimum TTL (I drew minimum TTL of 60 minutes out
> > from thin air). Would it be better?
> 
> enough to have a very high probability of succeeding before expiry (taking
> into account, loss, retries, etc.).

Usually DNS is fast.. 10 seconds? Or define PREF64_DISCOVERY_THRESHOLD to be 10 secs by default.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 17:31:55 +0000

Hi Simon,

Thank you for your review. On some of these I replied in another email, here for the rest:

> Of ext Simon Perreault
> Sent: 20. kesäkuuta 2012 17:20
> To: [email-masked]
> I would assume that the reason for the ISP's use of multiple DNS64 prefixes
> would be DNS-based NAT64 load balancing. The above prioritization breaks
> that. In any case, it would be best if the host would try to mimic the DNS64
> behaviour as much as possible so that the resulting NAT64 traffic patterns are
> not affected. That is, instead of picking one prefix and synthesizing a single
> AAAA record, synthesize a full AAAA RRset using all prefixes, and randomize
> the order of records.

The intent of the prioritization is to attempt avoiding possible issues if in future some meaning is encoded into suffix-fields of Figure 1 of RFC6052. The host cannot know what to put in suffixes of synthetized addresses, hence the host could try to avoid using Pref64::/n that has suffix-field. We could say that if there are multiple Pref64::/n of same priority available, a host SHOULD use them all in local synthesis process e.g. in round-robin manner? Would that suffice?

> I understand that vendor checks are preferred over ICMPv6, but I still think
> recommending ICMPv6 at all is wrong. ICMP can fail for a myriad of reasons,
> including ICMP echo reply rate limiting. It is just not a good protocol to
> recommend as a connectivity check. If you do want to recommend one, I
> would suggest STUN. I would also be fine with not recommending one and
> only discussing vendor-specific checks.

We recommend hosts to use vendor specific connectivity check servers with vendor specific protocols (which may be STUN). But for this operator hosted service... well, I guess STUN could be there as well (although it requires then STUN implementation for the host / application + STUN hosting. I'm not sure that is fair to require). After all, connectivity check is not that mandatory - host can just synthetize and see whether connections succeed or not.

> I would s/in order to avoid traversal through protocol translators// since
> there's no guarantee that IPv4 will not be NATed.

I didn't understand your comment.. The intent is to avoid IPv6->IPv4 protocol translation - not to avoid address translation..

> Suggestion: s/short-term/transition/

Ok

> It would be nice to note that DNS services that do NXRRSET hijacking will
> break this assumption.

You mean captive portals? Hmh.. do they return something even if the domain name is not in use? If so, we can add this and note that hijacking will not result in Pref64::/n discovery (unless the returned address actually contains well-known address:)

> >    IPv4 address, if possible.

Yes

> s/shall/SHALL/ ?

Yes

> Why not MUST?

Right.. Let's use MUST.

> What other IPv4 address? Isn't there a single well-known IPv4 address?

The intent is to define at least two well-known IPv4 addresses. Maybe two is enough, as three probably gives marginal benefit.

> This needs to be made more precise. Prefixes can't have PTR records (yet,
> there's a draft about that). Actually, I should be even more precise, since any
> domain name can "have" a PTR record. So, something like "For each
> Pref64::/n, there MUST be a PTR record for the domain name in the ip6.arpa
> tree corresponding to the Pref64:: address. That PTR record's value MUST be
> the corresponding NAT64 FQDN."

We explain what the PTR record should look like elsewhere in the document, but this can be clarified further.

> >    Pref64::/n discovery feature.

I do not believe any configurability requirement can be MUST in reality, as many kinds of devices and applications come with little to none configuration possibilities...

Best regards,

        Teemu

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Jun 2012 14:23:41 -0400

On 2012-06-20 12:44, [email-masked] wrote:
> A host implementation could very well use vendor specific well-known
> name as well and ignore this draft - it would work perfectly.
> However, for cases where vendor specific name is not available (maybe
> not all application writers, for example, do not have facilities to
> host their own names), the well-known name is useful.

Makes sense, thanks.

> I don't see how DNSSEC protecting PTR query would help in the
> "trusted domains" question. All that host could learn is that PTR
> query can be verified to be owned by badguys.hotspot.example.com,
> right?

I see.

I have two concerns with the trusted domains list.

My first concern is that it doesn't really add any security. If you come 
visit me to my office, where we run a NAT64, and I really want you to 
discover our prefix securely without you having to click through a scary 
dialog box, I will just squat the prefix of someone else who is probably 
already on the list (e.g., nokia.com), and route it to our NAT64 box. I 
didn't add any security, but somehow your client thinks this is secure. 
I just picked a different prefix, one that is in your client's "secure" set.

My second concern is that it allows the people who control domains that 
are on the list to do evil things. Here's an example attack: the owner 
of nokia.com, which is on the list, turns evil. He goes in any public 
NAT64 hotspot and starts a rogue DNS64 server with a Pref64::/n that 
belongs to nokia.com. That prefix is routed to a NAT64 that belongs to 
Nokia, somewhere in the Internet. The prefix will be "securely 
discovered" because all the appropriate DNS records are present and 
signed, the NAT64 works, and nokia.com is on the list, yet Nokia would 
be hijacking traffic.

In a nutshell, the proposed secure method of Pref64::/n discovery 
ensures that the DNS64 is controlled by an entity that also controls a 
domain name that is on a trusted list. That's not what "secure 
discovery" should be, IMHO. I would expect secure discovery to ensure 
that the DNS64 is controlled by the same entity that controls the 
network on which the client is.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Jun 2012 14:43:32 -0400

On 2012-06-20 13:31, [email-masked] wrote:
> The intent of the prioritization is to attempt avoiding possible
> issues if in future some meaning is encoded into suffix-fields of
> Figure 1 of RFC6052. The host cannot know what to put in suffixes of
> synthetized addresses, hence the host could try to avoid using
> Pref64::/n that has suffix-field. We could say that if there are
> multiple Pref64::/n of same priority available, a host SHOULD use
> them all in local synthesis process e.g. in round-robin manner? Would
> that suffice?

I think that would be fine if you only define two priority levels:
1. (highest priority) Prefix without suffix-field.
2. (lowest priority) Prefix with suffix-field.

> We recommend hosts to use vendor specific connectivity check servers
> with vendor specific protocols (which may be STUN). But for this
> operator hosted service... well, I guess STUN could be there as well
> (although it requires then STUN implementation for the host /
> application + STUN hosting. I'm not sure that is fair to require).

On the client side STUN is arguably easier than ICMP because you don't 
need access to raw sockets, it's just really simple UDP. On the server 
side ICMP has issues too because operating systems usually rate limit 
echo replies.

> After all, connectivity check is not that mandatory - host can just
> synthetize and see whether connections succeed or not.

Absolutely. I wouldn't mind if you just removed all references to ICMP 
without replacing them with STUN. My point is that recommending ICMP, 
even as an operator hosted service, really isn't a good idea because 
ICMP is really bad at this for a number of operational reasons.

>>> useful if DNS64 and NAT64 are present in dual-stack enabled
>>> access networks or if a node is multi-interfaced [RFC6418].  In
>>> such cases nodes may choose to prefer IPv4 or alternative network
>>> interface in order to avoid traversal through protocol
>>> translators.
>>
>> I would s/in order to avoid traversal through protocol
>> translators// since there's no guarantee that IPv4 will not be
>> NATed.
>
> I didn't understand your comment.. The intent is to avoid IPv6->IPv4
> protocol translation - not to avoid address translation..

You're right.

>>> A DNS reply with one or more non-empty AAAA records indicates
>>> that the access network is utilizing IPv6 address synthesis.
>>
>> It would be nice to note that DNS services that do NXRRSET
>> hijacking will break this assumption.
>
> You mean captive portals?

I was thinking of something like OpenDNS, but I guess some captive 
portals do it too.

> Hmh.. do they return something even if the
> domain name is not in use?

OpenDNS synthesizes an A RRset for domain names that don't exist 
(NXDOMAIN hijacking) as well as for domain names that do exist but don't 
have an A RRset (NXRRSET hijacking). They don't do it for AAAA, but I 
guess it's just a matter of time.

> If so, we can add this and note that
> hijacking will not result in Pref64::/n discovery (unless the
> returned address actually contains well-known address:)

Yes, that would be fine.

>>> The node should ensure a 32-bit IPv4 address value is present
>>> only once in an IPv6 address.  In case another instance of the
>>> value is found inside the IPv6, the node shall repeat the search
>>> with another IPv4 address, if possible.
>>
> The intent is to define at least two well-known IPv4 addresses. Maybe
> two is enough, as three probably gives marginal benefit.

Ok, it wasn't clear to me from the text. Maybe rephrase somehow...

> I do not believe any configurability requirement can be MUST in
> reality, as many kinds of devices and applications come with little
> to none configuration possibilities...

Ok.

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Jun 2012 14:51:00 -0700

...
> guess it's just a matter of time.

Chrome, and possibly other software, tests for such functionality
by looking up known-bogus FQDNs,
http://www.forensicswiki.org/wiki/Google_Chrome#Start-up_DNS_queries

> > returned address actually contains well-known address:)

I suggest,

  NXDOMAIN and NXRRSET hijacking may result in a false positive.
  One method to detect such hijacking is to query a FQDN that is
  known to be invalid (and normally return an empty response or
  an error response) and see if it returns a valid resource 
  record.

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 20 Jun 2012 15:38:45 -0700

> volunteers? Maybe Simon and/or Marc P.-H.?  Anyone else?

1. Section 3.2

It seems to me that using ICMP connectivity checks cannot be done with the
Well-Known Prefix, as it is not possible to register a PTR RR for each domain
using it.  This should be said somewhere as this is a good reason to prefer a
Network Specific Prefix if connectivity check are to be deployed in the future.

2. Section 3.3 "...to perform a function similar to ipv4-only.arpa, ..."

It should be "ipv4only.arpa"

Which bring another question:  Was the intent to use specifically
ipv4-only.<domain> (or ipv4only.<domain>), i.e. is the leftmost component
fixed, or is the whole domain name provisionable?

3. Appendix A "nat64.example.org IN AAAA..."

Why is that RR in the example?  I cannot find in the normative text how this
is used.  Besides it seems malformed (IP address is 14 bytes long, and the
"nat64.example.com." at the end of the line should be at the beginning of the
the next line).

Nits
====

- - Section 3.1.1, third bullet

s/MUST HAVE/MUST have/

- - Section 3.2 last paragraph

s/mode/node/

- - Section 3.3:

s/.  DNS For example/.  For example/

- -- 
Marc Petit-Huguenin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Jun 2012 12:27:36 +1000

Firstly this draft will not work with a non DNS64 aware intermediate
name servers as it will not understand the CD signaling.  This goup
needs to accept that intermediate name servers will need to be DNS64
aware and go back and redo RFC 6147 accepting that.

DNSSEC made the same mistake of trying to make a change work through
non DNSSEC aware servers.  We gave up trying to do that and accepted
that intermediate servers needed to be DNSSEC aware.

This working group has continually failed to understand how DNSSEC
works.  It wanted DNS64 to work with existing DNSSEC aware infrustucture
which was specifically designed to defeat what DNS64 does.

Instead of saying "We need to make intermediate resolvers DNS64
aware" and accept that DNS64 won't work until those servers are
upgraded the same way as dnsext said "We need to make intermediate
resolvers DNSSEC aware" it tried to do the impossible.

Sending a synthesised response to a DO=1 query is *insane* if the
NO DATA response is signed but that is what RFC 6147 says to do.

A sane thing to do would have been to add a EDNS extension which
returned the synthesised addresses along with the NO DATA response
to DNS64 aware clients (signalled by the presence of the option in
the query).

For non DNS64 aware clients you synthesis unless the synthesis can
be detected (DO=1 + a signed NODATA response) in which case you
send the signed NO DATA response.

The intermediate DNS64 aware recursive server would cache both the
NO DATA response and the synthesised addresses from the returned
option data.  For non DNS64 aware clients the synthesised responses
would be returned to clients that can't detect the synthesis and
NO DATA would be returned to those that can.  For DNS64 aware client
the full response would be sent.

The EDNS option could also be used to discover prefix information
if in addition to the addresses to also sent prefix length data.

Query:
	<code><opt-length=0>
Response:
	<code><opt-length=0>
or
	<code><opt-length><ttl>[<prefixlen><synthesised-address>]+

If the client has a trust relationship with its recursive server
to can trust the answer returned and use that to set AD as
appropriate to down stream clients.

EDNS support is manditory for IPv6 nodes.  There is no reason to
avoid using it.

Go back and fix RFC 6147 to work properly with DNSSEC.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Jun 2012 14:07:13 +1000

> aware and go back and redo RFC 6147 accepting that.

I suppose I should explain breakage.  CD=1 queries can be cached
after validation so you can't depend on CD=0 returning synthesised
records.
 
Mark

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 07:11:58 +0000

Simon,

> > I don't see how DNSSEC protecting PTR query would help in the "trusted
> > domains" question. All that host could learn is that PTR query can be
> > verified to be owned by badguys.hotspot.example.com, right?
> 
> I see.
> 
> My first concern is that it doesn't really add any security. If you come visit me
> to my office, where we run a NAT64, and I really want you to discover our
> prefix securely without you having to click through a scary dialog box, I will
> just squat the prefix of someone else who is probably already on the list (e.g.,
> nokia.com), and route it to our NAT64 box. I didn't add any security, but
> somehow your client thinks this is secure.

The client must always use network/transport/application layer security to be secure.

But I do know this "problem". I tried to tackle this in the previous I-D versions by writing that NAT64 FQDN should be served using split DNS and "nokia.com"'s  authoritative name server should respond to queries for NAT64 FQDN coming only from the "correct" access network (e.g. via whitelisted RDNSS). Hence if my host in your network would ask for NAT64 FQDN, it would not get positive response. That time people did not agree this is actually a real problem, and hence I ceased to think about solutions. 

Definitely the host can only trust the Pref64::/n is valid as such, but host cannot trust that it is used in correct network:-) 

Maybe when host is provisioned with trusted domains it is also provisioned with list of access networks where the domains are allowed to be used. Hence your "SSID" would not be found on the access network list and hence your service (or attack) would fail.

The attacks I can imagine you can launch with this are similar you can cause if you can send RAs to host (i.e. redirection, DoS).

I'm not sure we can solve this in easy manner - best is to start using end-to-end IPv6.

And I do not agree these problems are caused by heuristic draft, but effectively are present in NAT64/DNS64 framework already. Hence I don't see why these issues would be showstoppers for heuristic discovery. See below:

> My second concern is that it allows the people who control domains that are
> on the list to do evil things. Here's an example attack: the owner of nokia.com,
> which is on the list, turns evil. He goes in any public
> belongs to nokia.com. That prefix is routed to a NAT64 that belongs to Nokia,
> somewhere in the Internet. The prefix will be "securely discovered" because
> all the appropriate DNS records are present and signed, the NAT64 works, and
> nokia.com is on the list, yet Nokia would be hijacking traffic.

Right, but when compared to today's state the number of possible attackers actually decreases: only owners who control trusted domains can attack with "malicious" Pref64::/n.

Today anyone who can inject a hostile DNS64 address to a host's RDNSS list can launch the same hijacking attack.

So isn't this draft actually an improvement?-)

The beef again here I that the "secure discovery" does not mean the traffic sent using the securely discovered Pref64::/n goes to the right place, only that the destination address is securely formed. That is similar to DNSSEC anyway: with DNSSEC you can only be sure the destination address is valid - DNSSEC does not ensure the packets sent to valid address are delivered where they should. 

> In a nutshell, the proposed secure method of Pref64::/n discovery ensures
> that the DNS64 is controlled by an entity that also controls a domain name
> that is on a trusted list. That's not what "secure discovery" should be, IMHO. I
> would expect secure discovery to ensure that the DNS64 is controlled by the
> same entity that controls the network on which the client is.

So we agree on this, but do you agree this is a general problem, not heuristic-specific problem?

I mean even today when I talk to DNS64 in IPv6-only access network, I have no real means to tell I'm talking to legitimate DNS64. Maybe I can trust the DNS64 is legitimate if I learned it via pretty trusted channel, like 3GPP network L2 signaling.

So... host should have means to learn the DNS64 address first via secure means. SEND?-)

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 08:37:41 +0000

Hi Simon

> > multiple Pref64::/n of same priority available, a host SHOULD use them
> > all in local synthesis process e.g. in round-robin manner? Would that
> > suffice?
>

So how does network-side NAT64 load balancing actually work? Does it work so that a single Pref64::/n is used for a host, and different hosts see different Pref64::/n, or does a single host see multiple Pref64::/n?

If both are used in the field, then it would be ok for a node to stick using just one, right? (Picked e.g. pseudo-randomly from the learned Pref64::/n list)?

> On the client side STUN is arguably easier than ICMP because you don't need
> access to raw sockets, it's just really simple UDP. On the server side ICMP has
> issues too because operating systems usually rate limit echo replies.

Good points, let's discuss today.

> Absolutely. I wouldn't mind if you just removed all references to ICMP without
> replacing them with STUN. My point is that recommending ICMP, even as an
> operator hosted service, really isn't a good idea because ICMP is really bad at
> this for a number of operational reasons.

The intent was to provide some means for network to provide "standard" connectivity check services, hence leaving all protocols out would not suit that purpose very well. So let's discuss today if we should use STUN instead. I guess operator hosted STUN could provide additional benefits as well..

Best regards,

        Teemu

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 09:48:22 +0000

> trying to use DNSSEC.  If DANE/TLSA takes off, this will be a problem.
---
The security considerations follow closely those of RFC 6147 [RFC6147]. The possible attacks are very similar in the case where attacker controls DNS64 server and returns tampered IPv6 addresses to a node and in the case where attacker causes the node to  use tampered Pref64::/n for local address synthesis. Hence this document does not change the big picture for untrusted network scenarios. If an attacker mangles with Pref64::/n used by a DNS64 server or a node, the traffic generated by the node will be delivered to an altered destination. This can result in either a denial-of-service (DoS) attack (if the resulting IPv6 addresses are not assigned to any device), a flooding attack (if the resulting IPv6 addresses are assigned to devices that do not wish to receive the traffic), or an eavesdropping attack (in case the altered NSP is routed through the attacker).
---

Perhaps?

Teemu

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Jun 2012 09:22:23 -0400

>    an error response) and see if it returns a valid resource

Wfm.

Simon

---

From: <[email-masked]>
Date: Thu, 21 Jun 2012 13:28:17 +0000

Thank you Marc for your review, responses inline:

> Of ext Marc Petit-Huguenin
> Sent: 21. kesäkuuta 2012 01:39
> To: Dave Thaler
> Cc: [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 

Good point, added draft text to Connectivity Check section:"The Pref64::/n -based connectivity check approach works only with NSP, as it is not possible to register A record for each different domain using WKP."

> It should be "ipv4only.arpa"

Fixed, there were few of these.

 > Which bring another question:  Was the intent to use specifically ipv4-
> only.<domain> (or ipv4only.<domain>), i.e. is the leftmost component fixed,
> or is the whole domain name provisionable?
 
The idea was to have fixed "ipv4only.arpa" , i.e. no changes to left or right components.
 
> Why is that RR in the example?  I cannot find in the normative text how this is
> used.  Besides it seems malformed (IP address is 14 bytes long, and the
 
The section 3.1.2 section 4 performs AAAA query for NAT64 FQDN. Would the correct configuration be then:

nat64.example.com. 
              IN AAAA  2001:db8:0:0:0:0:0:0 
nat64.example.com. 
              IN A  192.0.2.1
 
> - - Section 3.1.1, third bullet

Fixed

> - - Section 3.2 last paragraph

Fixed, thanks.

> s/.  DNS For example/.  For example/

Fixed, thanks.

Best regards,

	Teemu

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Jun 2012 09:36:39 -0400

On 2012-06-21 03:11, [email-masked] wrote:
>> My first concern is that it doesn't really add any security. If you
>> come visit me to my office, where we run a NAT64, and I really want
>> you to discover our prefix securely without you having to click
>> through a scary dialog box, I will just squat the prefix of someone
>> else who is probably already on the list (e.g., nokia.com), and
>> route it to our NAT64 box. I didn't add any security, but somehow
>> your client thinks this is secure. I just picked a different
>> prefix, one that is in your client's "secure" set.
>
> But I do know this "problem". I tried to tackle this in the previous
> I-D versions by writing that NAT64 FQDN should be served using split
> DNS and "nokia.com"'s  authoritative name server should respond to
> queries for NAT64 FQDN coming only from the "correct" access network
> (e.g. via whitelisted RDNSS). Hence if my host in your network would
> ask for NAT64 FQDN, it would not get positive response. That time
> people did not agree this is actually a real problem, and hence I
> ceased to think about solutions.
>
> Definitely the host can only trust the Pref64::/n is valid as such,
> but host cannot trust that it is used in correct network:-)
>
> Maybe when host is provisioned with trusted domains it is also
> provisioned with list of access networks where the domains are
> allowed to be used. Hence your "SSID" would not be found on the
> access network list and hence your service (or attack) would fail.
>
> The attacks I can imagine you can launch with this are similar you
> can cause if you can send RAs to host (i.e. redirection, DoS).
>
> And I do not agree these problems are caused by heuristic draft, but
> effectively are present in NAT64/DNS64 framework already. Hence I
> don't see why these issues would be showstoppers for heuristic
> discovery. See below:

I agree with your assessment, and I also believe heuristic discovery 
should proceed forward. However, secure discovery might have to be 
dropped if all it does is provide a false sense of security.

>> My second concern is that it allows the people who control domains
>> that are on the list to do evil things. Here's an example attack:
>> the owner of nokia.com, which is on the list, turns evil. He goes
>> in any public NAT64 hotspot and starts a rogue DNS64 server with a
>> Pref64::/n that belongs to nokia.com. That prefix is routed to a
>> NAT64 that belongs to Nokia, somewhere in the Internet. The prefix
>> will be "securely discovered" because all the appropriate DNS
>> records are present and signed, the NAT64 works, and nokia.com is
>> on the list, yet Nokia would be hijacking traffic.
>
> Right, but when compared to today's state the number of possible
> attackers actually decreases: only owners who control trusted domains
> can attack with "malicious" Pref64::/n.
>
> Today anyone who can inject a hostile DNS64 address to a host's RDNSS
> list can launch the same hijacking attack.
>

Very tiny improvement. I still think it would give the user a false 
sense of security.

> The beef again here I that the "secure discovery" does not mean the
> traffic sent using the securely discovered Pref64::/n goes to the
> right place, only that the destination address is securely formed.

I presume "securely formed" means something different to you than it 
does to me...

> That is similar to DNSSEC anyway: with DNSSEC you can only be sure
> the destination address is valid - DNSSEC does not ensure the packets
> sent to valid address are delivered where they should.

With secure discovery you can't even be sure that the destination 
address is valid! All you can be sure of is that it is an address that 
belongs to somebody that also owns a domain in your trusted list. That 
is practically almost useless.

>> ensures that the DNS64 is controlled by an entity that also
>> controls a domain name that is on a trusted list. That's not what
>> "secure discovery" should be, IMHO. I would expect secure discovery
>> to ensure that the DNS64 is controlled by the same entity that
>> controls the network on which the client is.
>

Unsecure discovery is fine. It is just as unsecure as everything else.

But a secure discovery that is not secure at all is just misleading.

> I mean even today when I talk to DNS64 in IPv6-only access network, I
> have no real means to tell I'm talking to legitimate DNS64. Maybe I
> can trust the DNS64 is legitimate if I learned it via pretty trusted
> channel, like 3GPP network L2 signaling.
>

IMHO, secure discovery is not necessary. It would be nice if the DNSSEC 
method had worked, but I don't think it does.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Jun 2012 09:48:22 -0400

On 2012-06-21 04:37, [email-masked] wrote:
>> 1. (highest priority) Prefix without suffix-field. 2. (lowest
>> priority) Prefix with suffix-field.
>
> So how does network-side NAT64 load balancing actually work? Does it
> work so that a single Pref64::/n is used for a host, and different
> hosts see different Pref64::/n, or does a single host see multiple
> Pref64::/n?

Both possibilities are possible, and have pros and cons. It's just like 
regular DNS-based load balancing. Cameron Byrne would have more 
information, he looked into the problem pretty deeply.

See also these:
http://tools.ietf.org/html/draft-li-behave-dns64-load-balancing-02
http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-03
http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-01

> If both are used in the field, then it would be ok for a node to
> stick using just one, right? (Picked e.g. pseudo-randomly from the
> learned Pref64::/n list)?

No, because it would result in different traffic pattern from what would 
happen with normal DNS64. With normal DNS64, the node would pick one at 
random for each connection (ideally) or for each domain name (common 
because many apps have broken caching). If you just pick one at random 
for all your connections, you have a completely different traffic 
pattern, and that might cause problems because of unforeseen operational 
reasons. You want the traffic pattern to remain close to regular DNS64.

Simon

---

From: Aaron Yi DING <[email-masked]>
Date: Thu, 21 Jun 2012 18:09:34 +0300

Hello,

Concerning the security discussion so far, it's good to keep such 
section rather than dropping it IMHO,
since the main intention is to improve the security level of heuristic 
discovery.

The sense of false security as Simon cited is a pretty tricky topic, 
especially when we assume there will always be certain kind of imaginary 
attacks out there (though what Simon mentioned are indeed valid)

Such false security statement is just like the Carl Sagan's Dragon
http://www.users.qwest.net/~jcosta3/article_dragon.htm

To believe the approach as "insecure" is essentially a statement that 
can hardly be proven wrong, period.
Please kindly check Carl's dragon, If hard to comprehend.

The security section needs improvement, yes, but not dropped.

Thanks,
Aaron

On 21/06/12 16:36, Simon Perreault wrote:
> IMHO, secure discovery is not necessary. It would be nice if the 
> DNSSEC method had worked, but I don't think it does.
>
> Simon

---

From: <[email-masked]>
Date: Mon, 25 Jun 2012 06:00:31 +0000

Hi Aaron, Simon,

We discussed this a bit in the interim call, and I'm updating the draft to change the language from "Secure Learning of Pref64::/n" to "Validation of Discovered Pref64::/n" and add statements that all that this validation does is to verify the Pref64::/n is indeed one that ought to be used with a domain.

Best regards,

	Teemu

> From: ext Aaron Yi DING [mailto:[email-masked]]
> Sent: 21. kesäkuuta 2012 18:10
> To: Simon Perreault
> Cc: Savolainen Teemu (Nokia-NRC/Tampere); [email-masked]
> Concerning the security discussion so far, it's good to keep such section rather
> than dropping it IMHO, since the main intention is to improve the security
> level of heuristic discovery.
> 
> The sense of false security as Simon cited is a pretty tricky topic, especially
> when we assume there will always be certain kind of imaginary attacks out
> there (though what Simon mentioned are indeed valid)
> 
> To believe the approach as "insecure" is essentially a statement that can
> hardly be proven wrong, period.
> >>> your client thinks this is secure. I just picked a different prefix,
> >>> one that is in your client's "secure" set.
> >>
> >>> the owner of nokia.com, which is on the list, turns evil. He goes in
> >>> any public NAT64 hotspot and starts a rogue DNS64 server with a
> >>> records are present and signed, the NAT64 works, and nokia.com is on
> >>> the list, yet Nokia would be hijacking traffic.
> >>
> >>> ensures that the DNS64 is controlled by an entity that also controls
> >>> a domain name that is on a trusted list. That's not what "secure
> >>> discovery" should be, IMHO. I would expect secure discovery to
> >>> ensure that the DNS64 is controlled by the same entity that controls
> >>> the network on which the client is.
> >>

---

From: Aaron Yi DING <[email-masked]>
Date: Mon, 25 Jun 2012 10:30:49 +0300

Hi Teemu,

Thanks for your update. Replacing the term with 'validation' helps.

Look forward to the new version,
Aaron

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 25 Jun 2012 21:24:19 +0000

I've read the draft and have a question. There is a following requirement in RFC 6147:

>>The implementation SHOULD support mapping of separate IPv4 address
   ranges to separate IPv6 prefixes for AAAA record synthesis.  This
   allows handling of special use IPv4 addresses [RFC5735].

In case the DNS64 in the network is configured with several such (IPv4 address range)->(IPv6 prefix) mappings, how a host using the proposed heuristic can discover all such mappings? (without them, it seems the host would not be able to perform IPv6 address synthesis correctly for all possible IPv4 addresses the network DNS64 would be able to). 

Or is there something that makes the heuristic work even without discovery of all the mappings?

-Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Monday, June 18, 2012 5:00 PM
To: [email-masked]
Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

-Dave

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2012 10:14:32 +1000

In message <[email-masked]
rod.outlook.com>, Dmitry Anipko writes:
> In case the DNS64 in the network is configured with several such (IPv4 addres
> s range)->(IPv6 prefix) mappings, how a host using the proposed heuristic can
>  discover all such mappings? (without them, it seems the host would not be ab
> le to perform IPv6 address synthesis correctly for all possible IPv4 addresse
> s the network DNS64 would be able to). 
> 

You can't with draft-ietf-behave-nat64-discovery-heuristic.

One could encode the IPv4 address into QNAME and make AAAA queries.

	<DECIMAL>.ipv4only.arpa.

Where <DECIMAL> is the 32 bit decimal value of the IPv4 address
with no leading zeros.  There is no need to split the address into
octets or nibbles as there is no delegation needed.

The server behaves as if "<DECIMAL>.ipv4only.arpa. A <DECIMAL>"
exists.

---

From: <[email-masked]>
Date: Tue, 26 Jun 2012 14:19:48 +0000

Hi,

> In case the DNS64 in the network is configured with several such (IPv4
> address range)->(IPv6 prefix) mappings, how a host using the proposed
> heuristic can discover all such mappings? (without them, it seems the host
> would not be able to perform IPv6 address synthesis correctly for all possible
> IPv4 addresses the network DNS64 would be able to).
> 

The more interesting question perhaps is what this draft should say about synthesis... It is now (in latest under-work version) saying only that all Pref64::/n should be used in synthesis, but it is not stating ANYTHING about what IPv4 addresses can be used in the synthesis. I was actually thinking to leave that part out of this prefix discovery draft.

But basically a node implementing DNS64 by itself would just not implement that "SHOULD", because the node has no information about mapping data. 

Best regards,

Teemu

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 26 Jun 2012 18:19:02 +0000

>> The more interesting question perhaps is what this draft should say about synthesis... It is now (in latest under-work version) saying only that all Pref64::/n should be used in synthesis, but it is not stating ANYTHING about what IPv4 addresses can be used in the synthesis.

I think essentially it is the same question - without some additional knowledge (such as e.g. of range->prefix mappings), the host can't answer either of the questions correctly (either how to synthesize IPv6 based on given IPv4, or whether to synthesize IPv6 for a given IPv4).

>> I was actually thinking to leave that part out of this prefix discovery draft....But basically a node implementing DNS64 by itself would just not implement that "SHOULD", because the node has no information about mapping data.

I'm not sure that would be sufficient - the node then still could synthesize IPv6 incorrectly, and that could lead to added connectivity issues (IPv6 connection timeouts), not present without DNS64 function in the node, as well as to unanticipated effects on the network NAT64 device (increased error reporting, unanticipated traffic load, etc.). Or perhaps I misunderstood what you meant with "not implement"?

If the current text is standardized as is, then IMO we can end up in a somewhat strange situation where two entities following two standards, which were meant to work together, actually don't always interoperate. A couple of things that could be done to mitigate/address that: 

1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it doesn't work with network DNS64s configured with different IPv6 prefixes for different IPv4 ranges. (and then it would make sense to change RFC6147 SHOULD to SHOULD NOT for any addresses that are likely to be used on the wire)

2. Come up with a procedure, which operator of network DNS64 & node DNS64 could use, if the network DNS64 is configured with such different prefixes, to enable in-node DNS64 to learn the necessary information.

Thanks,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 26, 2012 7:20 AM
To: Dmitry Anipko; Dave Thaler; [email-masked]
Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

Hi,

Best regards,

Teemu

---

From: <[email-masked]>
Date: Tue, 26 Jun 2012 18:45:04 +0000

Hi,

> I think essentially it is the same question - without some additional knowledge
> (such as e.g. of range->prefix mappings), the host can't answer either of the
> questions correctly (either how to synthesize IPv6 based on given IPv4, or
> whether to synthesize IPv6 for a given IPv4).

In which case and from where the host would get special use IPv4 address literals? Being in IPv6-only access and encountering literal net10 addresses in html? 

I mean, in the common case host performs AAAA query for a name and it can get synthesized IPv6 address from DNS64 that has this mapping capability (and can return synthetic IPv6 address containing IPv4 address from special group). I would assume this would be the most common case.

It is true that this would not work if the host gets a special use IPv4 address literal from somewhere, but how common is that?

I mean if the access network (enterprise, cellular, e.g.) would want their IPv6-only hosts to access their IPv4-only devices that are numbered with special use IPv4 addresses, why the said organization would not create AAAA records containing IPv6 addresses pointing to NAT64, or otherwise ensure their IPv6-only hosts do not encounter these special use IPv4 address literals? Or the organization would ensure the packets flow correctly when hosts use discovered Pref64::/n in combination with special use addresses.

> I'm not sure that would be sufficient - the node then still could synthesize IPv6
> incorrectly, and that could lead to added connectivity issues (IPv6 connection
> timeouts), not present without DNS64 function in the node, as well as to
> unanticipated effects on the network NAT64 device (increased error
> reporting, unanticipated traffic load, etc.). Or perhaps I misunderstood what
> you meant with "not implement"?

If the node would get these special use IPv4 address literals and synthesize based on those (but network is not prepared to for node to use discovered Pref64::/n with those addresses), then sure, it would take a while for connection attempts to fail. But we have happy eyeballs:)

> If the current text is standardized as is, then IMO we can end up in a
> somewhat strange situation where two entities following two standards,
> which were meant to work together, actually don't always interoperate. A
> couple of things that could be done to mitigate/address that:

Which entities do not interoperate? 

> 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it doesn't work
> with network DNS64s configured with different IPv6 prefixes for different IPv4
> ranges. (and then it would make sense to change RFC6147 SHOULD to
> SHOULD NOT for any addresses that are likely to be used on the wire)

It would work, if the NAT64 to which packets using discovered Pref64::/n are routed can reach these special use addresses. I.e. maybe the routing would not be as efficient as with the prefix network's DNS64 would've used for these IPv4 ranges, but packets could flow nevertheless.

I mean I don't understand the use case when different IPv6 prefix is needed for different IPv4 ranges, unless for route optimization. And if the route optimization is all that there is, then is there really a problem if some packets do not follow the most optimal route?
 
> 2. Come up with a procedure, which operator of network DNS64 & node
> DNS64 could use, if the network DNS64 is configured with such different
> prefixes, to enable in-node DNS64 to learn the necessary information.

This would require some sort of policy distribution mechanism, and the design requirement we had is that there must not be any DNS64 changes.

In my opinion we can write a section about implications of special use IPv4 addresses and lack of support for specific IPv4 ranges, but state that iff the host actually encounters these literals, and synthesizes IPv6 addresses with Pref64::/n, the network ought to be able to route packets correctly nevertheless, and the host should provide graceful failure experience for the user (which the host anyway does, TCP SYNs can get lost anyway).

Best regards,

	Teemu

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Jun 2012 15:27:36 -0700

On 06/21/2012 06:28 AM, [email-masked] wrote:
>> [mailto:[email-masked]] On Behalf Of ext Marc Petit-Huguenin 
>> Sent: 21. kesäkuuta 2012 01:39 To: Dave Thaler Cc: [email-masked] 
>> draft-ietf-behave-nat64-discovery-heuristic- 09
>> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 

[...]

>> Why is that RR in the example?  I cannot find in the normative text how
>> this is used.  Besides it seems malformed (IP address is 14 bytes long,
>> and the "nat64.example.com." at the end of the line should be at the
>> beginning of the the next line).
> 
> nat64.example.com. IN AAAA  2001:db8:0:0:0:0:0:0 nat64.example.com. IN A
> 192.0.2.1

If it is only for DNSSEC, then the AAAA record is useless for a configuration
that does not use DNSSEC, right?

I found an additional small issue:

4. Section 3.2, 7th paragraph

The text does not say how long an implementation should wait after sending the
3rd ICMPv6 packet before deciding that the Pref64:: is not functioning.

FYI I published a partial implementation of this draft as free software:

http://blog.marc.petit-huguenin.org/2012/06/nat64-discovery.html

Thanks.

- -- 
Marc Petit-Huguenin

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 12:58:37 +0000

Dmitry, how about following piece of text as new subsection:
--
Mapping of IPv4 Address Ranges to IPv6 Prefixes

   The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map
   specific IPv4 address ranges to separate Pref64::/n.  That allows
   handling of special use IPv4 addresses [RFC5735].

   The heuristic discovery method described herein does not support
   learning of the possible rules used by DNS64 server for mapping
   specific IPv4 address ranges to separate Pref64::/n.  Therefore,
   nodes will use the same discovered Pref64::/n to synthesize IPv6
   addresses out from any IPv4 address.  The operator of the NAT64 and
   the DNS64 ought to take this into account in the network design and
   support routing, even if not optimal, of the packets nodes have
   synthesized by combining the discovered Pref64::/n and the IPv4
   address nodes have learned via DNS or obtained as referrals.
--

Best regards,

        Teemu

> Of Savolainen Teemu (Nokia-NRC/Tampere)
> Sent: 26. kesäkuuta 2012 21:45
> To: [email-masked]; [email-masked]; [email-masked]
> > I think essentially it is the same question - without some additional
> > knowledge (such as e.g. of range->prefix mappings), the host can't
> > answer either of the questions correctly (either how to synthesize
> > IPv6 based on given IPv4, or whether to synthesize IPv6 for a given IPv4).
>
> In which case and from where the host would get special use IPv4 address
> literals? Being in IPv6-only access and encountering literal net10 addresses in
> html?
>
> I mean, in the common case host performs AAAA query for a name and it can
> get synthesized IPv6 address from DNS64 that has this mapping capability
> (and can return synthetic IPv6 address containing IPv4 address from special
> group). I would assume this would be the most common case.
>
> It is true that this would not work if the host gets a special use IPv4 address
> literal from somewhere, but how common is that?
>
> I mean if the access network (enterprise, cellular, e.g.) would want their IPv6-
> only hosts to access their IPv4-only devices that are numbered with special
> use IPv4 addresses, why the said organization would not create AAAA records
> containing IPv6 addresses pointing to NAT64, or otherwise ensure their IPv6-
> only hosts do not encounter these special use IPv4 address literals? Or the
> organization would ensure the packets flow correctly when hosts use
> discovered Pref64::/n in combination with special use addresses.
>
> > I'm not sure that would be sufficient - the node then still could
> > synthesize IPv6 incorrectly, and that could lead to added connectivity
> > issues (IPv6 connection timeouts), not present without DNS64 function
> > in the node, as well as to unanticipated effects on the network NAT64
> > device (increased error reporting, unanticipated traffic load, etc.).
> > Or perhaps I misunderstood what you meant with "not implement"?
>
> If the node would get these special use IPv4 address literals and synthesize
> based on those (but network is not prepared to for node to use discovered
> Pref64::/n with those addresses), then sure, it would take a while for
> connection attempts to fail. But we have happy eyeballs:)
>
> > which were meant to work together, actually don't always interoperate.
> > A couple of things that could be done to mitigate/address that:
>
> > 1. Say in the draft-ietf-behave-nat64-discovery-heuristic that it
> > doesn't work with network DNS64s configured with different IPv6
> > prefixes for different IPv4 ranges. (and then it would make sense to
> > change RFC6147 SHOULD to SHOULD NOT for any addresses that are likely
> > to be used on the wire)
>
> It would work, if the NAT64 to which packets using discovered Pref64::/n are
> routed can reach these special use addresses. I.e. maybe the routing would
> not be as efficient as with the prefix network's DNS64 would've used for these
> IPv4 ranges, but packets could flow nevertheless.
>
> I mean I don't understand the use case when different IPv6 prefix is needed
> for different IPv4 ranges, unless for route optimization. And if the route
> optimization is all that there is, then is there really a problem if some packets
> do not follow the most optimal route?
>
> > DNS64 could use, if the network DNS64 is configured with such
> > different prefixes, to enable in-node DNS64 to learn the necessary
> information.
>
> This would require some sort of policy distribution mechanism, and the design
> requirement we had is that there must not be any DNS64 changes.
>
> In my opinion we can write a section about implications of special use IPv4
> addresses and lack of support for specific IPv4 ranges, but state that iff the
> host actually encounters these literals, and synthesizes IPv6 addresses with
> Pref64::/n, the network ought to be able to route packets correctly
> nevertheless, and the host should provide graceful failure experience for the
> user (which the host anyway does, TCP SYNs can get lost anyway).
>
> Best regards,
>
>       Teemu

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 13:06:46 +0000

Hi Marc,

Comments inline:

> From: ext Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: 27. kesäkuuta 2012 01:28
>

Right. For DNSSEC-less function there's no need for AAAA record for NAT64 FQDN.

> The text does not say how long an implementation should wait after sending
> the 3rd ICMPv6 packet before deciding that the Pref64:: is not functioning.
 
The connectivity check is starting to be a long lasting procedure (1 sec + 3 sec + something).. Which is pretty long. Maybe that should be squeezed to 1+2+3 seconds? Like this:
--
If no response is received for the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo Request, a second later.  If still no response is received, the node SHALL send a third ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is received, the node knows the IPv6 path to the connectivity check server is functioning normally.  If, after the three transmissions and three seconds since the last ICMPv6 Echo Request, no response is received, the node learns this Pref64::/n might not be functioning.....
--
 
> http://blog.marc.petit-huguenin.org/2012/06/nat64-discovery.html

Thank you for this work, we now have at least two partial implementations (the one we did earlier and now yours). I definitely agree with you that implementations are the best way to review I-Ds:)

Best regards,
	
	Teemu

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 27 Jun 2012 07:05:11 -0700

[...]
>> The text does not say how long an implementation should wait after
>> sending the 3rd ICMPv6 packet before deciding that the Pref64:: is not 
>> functioning.
> 
> The connectivity check is starting to be a long lasting procedure (1 sec +
> 3 sec + something).. Which is pretty long. Maybe that should be squeezed
> to 1+2+3 seconds? Like this: -- If no response is received for the ICMPv6
> Echo Request, the node SHALL send another ICMPv6 Echo Request, a second
> later.  If still no response is received, the node SHALL send a third
> ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is
> received, the node knows the IPv6 path to the connectivity check server is
> functioning normally. If, after the three transmissions and three seconds
> since the last ICMPv6 Echo Request, no response is received, the node
> learns this Pref64::/n might not be functioning..... --

I am surprised that there is not already an RFC somewhere describing how to do
connectivity checks with ICMP[v6].  Perhaps it would be simpler to reuse the
rules used by STUN:

https://tools.ietf.org/html/rfc5389#section-7.2.1

- -- 
Marc Petit-Huguenin

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 27 Jun 2012 09:07:39 -0600

Hi Teemu and Marc,

> >> sending the 3rd ICMPv6 packet before deciding that the Pref64:: is
> >> not functioning.
> >
> > 3 sec + something).. Which is pretty long. Maybe that should be
> > squeezed to 1+2+3 seconds? Like this: -- If no response is received
> > for the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo
> > Request, a second later.  If still no response is received, the node
> > SHALL send a third
> > received, the node knows the IPv6 path to the connectivity check
> > server is functioning normally. If, after the three transmissions
and
> > three seconds since the last ICMPv6 Echo Request, no response is
> > received, the node learns this Pref64::/n might not be
> > functioning..... --
> 
> I am surprised that there is not already an RFC somewhere describing
> how to do connectivity checks with ICMP[v6].  Perhaps it would be
> simpler to reuse the rules used by STUN:
> 

I agree with Marc, there has to be some standardized way of doing those
checks should they be needed. However, I'm not so sure that the are
needed. RFC6147 is not requiring the DNS64 server to perform any
connectivity checks.  Does it really add any value to do those types of
checks for client learning the prefix?

/Stephan

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 18:34:45 +0000

> I am surprised that there is not already an RFC somewhere describing how to
> do connectivity checks with ICMP[v6].  Perhaps it would be simpler to reuse
> the rules used by STUN:
>

That sounds more complex / overkill for me.. What benefit does that complex RTO estimation give here?

If we'd use fixed initial value of 1s for RTO, and then define Rc to be e.g. 7, and have final "Rm" like 3 (seconds), isn't that close enough? That would result in 10 seconds until failure?

Best regards,

Teemu

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 18:39:35 +0000

> checks should they be needed. However, I'm not so sure that the are needed.
> RFC6147 is not requiring the DNS64 server to perform any connectivity
> checks.  Does it really add any value to do those types of checks for client
> learning the prefix?

That has been under debate - one way indeed would be to drop the whole connectivity check section.

If the connectivity check fails, the node will anyway be in doubt whether it is just the connectivity check that doesn't work... and just using the Pref64::/n would actually yield in working system. Hence node might anyway go forward using the discovered Pref64::/n (as the only alternative would be no connection for sure). For diagnostic purposes (and faster error recoveries) the connectivity test failure might give a hint that problem could be in prefix discovery (or NAT64 system in general).

Without connectivity check defined here, the nodes would either just use the Pref64::/n and maybe see connections not working with synthetic addresses, and/or implementations could just choose to (not) have their proprietary connection check systems like today.

I.e. we could separate the connectivity check out from here, if wanted to be so.

Best regards,

        Teemu

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 27 Jun 2012 15:14:31 -0700

On 06/27/2012 11:34 AM, [email-masked] wrote:
>> I am surprised that there is not already an RFC somewhere describing how
>> to do connectivity checks with ICMP[v6].  Perhaps it would be simpler to
>> reuse the rules used by STUN:
>> 
> If we'd use fixed initial value of 1s for RTO, and then define Rc to be
> e.g. 7, and have final "Rm" like 3 (seconds), isn't that close enough? That
> would result in 10 seconds until failure?
> 

My point was that an existing algorithm should be used, instead of designing a
new one.

But I thought a little bit more about this and I agree with Simon that using
ICMPv6 as the baseline connectivity check is not a good idea, but for a
different reason:  Most of the code that would need to synthesize IPv6
addresses will run in applications.  But sending ICMPv6 packets requires root
(or something equivalent) and that's generally a bad idea for an application.

So my preference would be to have a baseline connectivity protocol that does
not require root.  It can be STUN, or a TCP connection to port 7, or a UDP
connection to port 7 with a retransmission algorithm identical to the STUN - I
do not really care, but the draft must mandate one, and must mandate that this
baseline protocol is active on the hostname if a PTR RR is installed.

After this it is always possible to define a S-NAPTR application to publish
the other connectivity protocols available at the hostname in the PTR RR.

- -- 
Marc Petit-Huguenin

---

From: Dave Thaler <[email-masked]>
Date: Wed, 27 Jun 2012 22:22:41 +0000

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2012 3:15 PM
> To: [email-masked]
> Cc: Dave Thaler; [email-masked]
> > If we'd use fixed initial value of 1s for RTO, and then define Rc to
> > be e.g. 7, and have final "Rm" like 3 (seconds), isn't that close
> > enough? That would result in 10 seconds until failure?
> >
> 
> My point was that an existing algorithm should be used, instead of designing
> a new one.

Ping isn't a new algorithm.

> addresses will run in applications.

Legitimate question: Do you have data to support that ("most")?

> But sending ICMPv6 packets requires root
> So my preference would be to have a baseline connectivity protocol that
> does not require root.  It can be STUN, or a TCP connection to port 7, or a
> UDP connection to port 7 with a retransmission algorithm identical to the
> STUN - I do not really care, but the draft must mandate one, and must
> mandate that this baseline protocol is active on the hostname if a PTR RR is
> installed.
> 
> After this it is always possible to define a S-NAPTR application to publish the
> other connectivity protocols available at the hostname in the PTR RR.

Personally, I don't think we should standardize anything around S-NAPTR.

-Dave

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJP64WLAAoJECnERZXWan7Er7EQAKXxO5BaOMJMpdQySk
> Hlq/2p
> 4oPyISxTxlYeGOcQhZheInCb5IYw+2BbeTfLTAau54LuEpCyUI9MHCah5b4k7vn
> 4
> WsHl44UJ2gc5cI58r6snsipv2j6+Jltmg1k+JntJoNXwhChZMuu7gkKoZRvXIclk
> C3kt2Rv8ghRsXZ+3j1DLNNjDLr/8+35GPA47kvIc/8J3dPjUUuVT9S94VMxCuam
> L
> vChbZ1tPKyeJlNBqB6BfV0k0rmgODBByDvA+Y8wH1paEGLtL5qu6waWjYNpFw
> csX
> eD9vkabnI6/mQX1dwpdHfjnSvDP8Zitq5mMlqRhpO1ul07tqzdJRgBbdrrwHGJb
> l
> N+/ahuGHO1nuCOF7RTbRW1G/VbnZL80NSM+ZyiaodrxhLDtSG2e6Ru7Cc8Oc
> RNLy
> I0UWwQiYFqm3UARccBr0lwTTDed9rHoNi1vjtR+DAohf7ZepIxQveA2P7eBBJ9
> vY
> s5bkRVm8YyS2xkU+Eyz7xjS4JbJVgLE3iC2gvjDmpEhe2DDHIEWVF48tsSVnW6
> w3
> ukBnawn16osAGabiaO4gBy01XGnJXDDug5rtQE8DvQsZk77uwsaWmWVtMst
> PCTYx
> U7Rty4WfUYTBK/WGlWFX8QVbNfKzvFesyD00wg1/2R6uUmLAMVmohzMvX
> YmiEHeP
> dq/axJALGsDchu0th9WG
> =HUMl
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 27 Jun 2012 15:43:51 -0700

On 06/27/2012 03:22 PM, Dave Thaler wrote:
>> -----Original Message----- From: Marc Petit-Huguenin
>> [mailto:[email-masked]] Sent: Wednesday, June 27, 2012 3:15 PM To:
>> [email-masked] Cc: Dave Thaler; [email-masked] Subject: Re:
>> [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic- 09
>> 
>>>>> I am surprised that there is not already an RFC somewhere
>>>>> describing how to do connectivity checks with ICMP[v6].  Perhaps it
>>>>> would be simpler to reuse the rules used by STUN:
>>>>> 
> My point was that an existing algorithm should be used, instead of
> designing a new one.
> 

Yes, but ping (with default options) is a continuous connectivity check,
whereas the usage in nat64-discovery-heuristic is more like the ICE
connectivity check.

> 
> But I thought a little bit more about this and I agree with Simon that
> using ICMPv6 as the baseline connectivity check is not a good idea, but for
> a different reason:  Most of the code that would need to synthesize IPv6 

No, but SIP and SDP look like good candidates for protocols carrying IPv4
addresses that would require to be converted to IPv6 addresses in a NAT64
environment, and applications using these protocols are generally not run
under root.

> 
> But sending ICMPv6 packets requires root (or something equivalent) and
> that's generally a bad idea for an application.
> 
> does not require root.  It can be STUN, or a TCP connection to port 7, or
> a UDP connection to port 7 with a retransmission algorithm identical to
> the STUN - I do not really care, but the draft must mandate one, and must 
> mandate that this baseline protocol is active on the hostname if a PTR RR
> is installed.
> 

I like S-NAPTR :-)

- -- 
Marc Petit-Huguenin

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 28 Jun 2012 00:13:51 +0000

Hi Teemu,

>>> It is true that this would not work if the host gets a special use 
> IPv4 address literal from somewhere, but how common is that?

If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-09, same use cases if they make sense in e.g. enterprise network using RFC 1918 addresses, in such network will result in 10.* literals. Do use cases of draft-ietf-behave-nat64-discovery-heuristic-09 apply to enterprise networks (or homenet) or other networks, which have legacy parts using RFC 1918 space? E.g. a network which has new IPv6-only segment, and some legacy segment/servers with IPv4 addressing, to which IPv6 only can only connect using DNS64/NAT64?

> connection attempts to fail. But we have happy eyeballs:)

HE is supposed to fix existing brokenness. We don't want to create new brokenness and rely on HE to fix it.

> requirement we had is that there must not be any DNS64 changes.

Is this a goal for nodes implementing the heuristic to be able to use the heuristic on any network with DNS64, or only on a special network that has been designed for them? (as the text you proposed suggests)

I think we need to better understand the reasoning behind the RFC 6147 SHOULD- perhaps RFC 6147 authors and folks who deploy NAT64 in different environments could help to advice whether it is likely to have e.g. two NAT64 on the network (e.g. one is for internal network IPv4 island, the other one is for access to IPv4 Internet), and if so - whether it is possible&feasible for those NATs to handle traffic with incorrectly synthesized addresses without breaking connectivity. 

If nobody actually is/will be deploying such configurations, I agree there is no practical problem. 

If some people are deploying configurations with multiple not chained NATs, and there is no way to make them work with incorrectly synthesized addresses, then there is a problem that has not been addressed.

If people are deploying such configurations, and there is a way to make them work without breaking connectivity, then the only consideration is whether it is acceptable to require that the network which the node visits needs to be re-configured in order for the node to be able to use the heuristic. If it is acceptable, I think the text you proposed would benefit if it is elaborated how the network shall be designed to handle this case, but otherwise it looks good to me.

Thank you,
Dmitry.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2012 5:59 AM
To: Dmitry Anipko; Dave Thaler; [email-masked]
Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

Best regards,

        Teemu

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Jun 2012 18:19:18 -0700

> Behalf Of Dmitry Anipko
> Sent: Wednesday, June 27, 2012 5:14 PM
> To: [email-masked]; Dave Thaler; [email-masked]
> If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-
> 09, same use cases if they make sense in e.g. enterprise network using
> RFC 1918 addresses, in such network will result in 10.* literals. Do
> use cases of draft-ietf-behave-nat64-discovery-heuristic-09 apply to
> enterprise networks (or homenet) or other networks, which have legacy
> parts using RFC 1918 space? E.g. a network which has new IPv6-only
> segment, and some legacy segment/servers with IPv4 addressing, to which
> IPv6 only can only connect using DNS64/NAT64?

What we are effectively describing is a routing table:

  IPv4 destination    NAT64 prefix
  ----------------    ------------
     10.1.0.0/16      2001:db8:1
     10.2.0.0/16      2001:db8:1
     192.168.1/24     2001:db8:3
     192.168.2/24     2001:db8:4
    
The simple solution is declare that out of scope, and say that the
DNS64 heuristic doesn't support unique NAT64 prefixes per IPv4 prefix.

We have always known the DNS64 heuristic is not ideal, is not 
perfect, and somewhat of a documented kludge.  Andrew Sullivan has 
more colorful, and accurate, summary of the DNS64 heuristic.

The harder solution is to specify how to build ipv4only.arpa
queries for each different destination IPv4 prefix.  ISPs would
wildcard their ipv4only.arpa resource record (attracting all
destination traffic to their NAT64).

> Is this a goal for nodes implementing the heuristic to be able to use
> the heuristic on any network with DNS64, or only on a special network
> that has been designed for them? (as the text you proposed suggests)
> 
> I think we need to better understand the reasoning behind the RFC 6147
> SHOULD- perhaps RFC 6147 authors and folks who deploy NAT64 in
> different environments could help to advice whether it is likely to
> have e.g. two NAT64 on the network (e.g. one is for internal network
> IPv4 island, the other one is for access to IPv4 Internet), and if so -
> whether it is possible&feasible for those NATs to handle traffic with
> incorrectly synthesized addresses without breaking connectivity.

The idea, as I recall it, was to allow an ISP to operate two NAT64
devices, one going to the Internet, the other connecting to an IPv4-only
datacenter (IMAP servers, WWW servers, media streamers, etc.), like
this,

                       NAT64-------IPv4-only servers in datacenter
                      /
   IPv6-only host----<
                      \
                       NAT64------IPv4 Internet

> there is no practical problem.

Deployments like the above, without IPv6 anywhere (just IPv4 and NAT44) do
exist.

> If some people are deploying configurations with multiple not chained
> NATs, and there is no way to make them work with incorrectly
> synthesized addresses, then there is a problem that has not been
> addressed.
> 
> If people are deploying such configurations, and there is a way to make
> them work without breaking connectivity, then the only consideration is
> whether it is acceptable to require that the network which the node
> visits needs to be re-configured in order for the node to be able to
> use the heuristic. If it is acceptable, I think the text you proposed
> would benefit if it is elaborated how the network shall be designed to
> handle this case, but otherwise it looks good to me.

I would declare it as acceptable.  Routing on the last 32 bits of
the IPv6 _is_ possible, or if that is undesirable, adjust the NAT64
mapping so the IPv4 address is earlier in the IPv6 address.  The
heuristic and the NAT64 addressing format support either choice.  In
this way, the same NAT64 prefix is used, but a router in front of
the two NAT64's causes the packets to go one way or the other:

                       NAT64-------IPv4-only servers in datacenter
                       /
   IPv6-only host----router
                       \
                       NAT64------IPv4 Internet

Appropriate filtering -- which probably is already present -- would
be needed on the 'other' NAT64 (e.g., so 10.0.0.0/8 doesn't appear
on the Internet-connected NAT64).

-d

> Behalf
> > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-
> heuristic-
> > 09
> >
> > Hi,
> >
> IPv4 address

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 06:49:00 +0000

> DNS64 heuristic doesn't support unique NAT64 prefixes per IPv4 prefix.

I think that is what we should do - the heuristic will not discover these mappings, and the ISP should configure their networks so that the impact is minimal - see below about this.
 
> The harder solution is to specify how to build ipv4only.arpa queries for each
> different destination IPv4 prefix.  ISPs would wildcard their ipv4only.arpa
> resource record (attracting all destination traffic to their NAT64).

But how many IPv4 prefixes there are... 4 billion queries to learn mapping for all 2^32 possible /32 destinations ranges?-)

> The idea, as I recall it, was to allow an ISP to operate two NAT64 devices, one
> going to the Internet, the other connecting to an IPv4-only datacenter (IMAP
> servers, WWW servers, media streamers, etc.), like this,
> 

This mapping of IPv4 address ranges to IPv6 addresses problem for heuristics only in the case of NAT64 being close to the IPv6 host? Right?

In the above example, if the setup is static, I would suggest ISP to create signed AAAA records for the IPv4-only servers in the datacenters (using Pref64::/n of the NAT64 above), in which case the IPv6-only DNSSEC using host would get signed AAAA response from the DNS, and would use that (no need for local synthesis). I.e. from host point of view it would be talking to "real" IPv6 destination.

Also, in the case of non-DNSSEC using IPv6-only host, it is enough that ISP's DNS64 returns synthetic AAAA records for the servers in datacenter.

Now in case the ISP does not want to provide signed AAAA records for the servers in data center, but host does DNSSEC validation (or otherwise gets IPv4 literal), then the packets from the host could end up using Pref64::/n of the below NAT64, and packets would be sent using "incorrect" Pref64::/n. However, in case of ISP, why the ISP could not have more specific routes that would ensure the packets host sends to Pref64_of_below_NAT64:IPv4addressofdatacenter would be actually routed to the above NAT64, and not to Internet-leading NAT64? .. . and I notice this is what you propose below:)

> I would declare it as acceptable.  Routing on the last 32 bits of the IPv6 _is_
> possible, or if that is undesirable, adjust the NAT64 mapping so the IPv4
> address is earlier in the IPv6 address.  The heuristic and the NAT64 addressing
> format support either choice.  In this way, the same NAT64 prefix is used, but
> a router in front of the two NAT64's causes the packets to go one way or the
> other:
> 
> Appropriate filtering -- which probably is already present -- would be needed
> on the 'other' NAT64 (e.g., so 10.0.0.0/8 doesn't appear on the Internet-
> connected NAT64).

Maybe I'll draw this picture into the draft to explain how this can be made to work, if used by ISP?

But generally I would even more prefer for ISP to ensure the IPv6-only host does not get IPv4 address literal for its servers in datacenters, but instead provides signed AAAA records for those servers.

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 07:44:40 +0000

Marc,

> My point was that an existing algorithm should be used, instead of designing a

That's the implementation specific option. Your (application) implementation can use STUN, or some HTTP-based proprietary scheme (for example),  if it likes with your own connectivity check server. We do not want to create new protocol dependencies/requirements here - and requiring STUN or similar would be one.

If it is too difficult to agree on default connectivity check protocol, we can just drop the default connectivity check out from the specification and state that if implementation wants assurances other than just trying to establish connections, the implementation can use their own connectivity check systems.

Best regards,

        Teemu

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 08:30:57 +0000

Hi Dmitry,

Based on your and Dan's email, I updated the section to look as following:
-----start-------
5.1.  Mapping of IPv4 Address Ranges to IPv6 Prefixes

   The RFC 6147 [RFC6147] allows DNS64 implementations to be able to map
   specific IPv4 address ranges to separate Pref64::/n.  That allows
   handling of special use IPv4 addresses [RFC5735].  The example setup
   where this might be used is illustrated in Figure 1.  The NAT64 "A"
   is used when accessing IPv4-only servers in the datacenter, and the
   NAT64 "B" is used for Internet access.

                       NAT64 "A" ----- IPv4-only servers in a datacenter
                      /
   IPv6-only host----<
                      \
                       NAT64 "B" ----- IPv4 Internet

                 Figure 1: NAT64s with IPv4 Address Ranges

   The network operators can help IPv6-only hosts by ensuring the IPv6-
   hosts do not have to work with IPv4 address literals.  That is, the
   IPv4-only servers ought to have signed AAAA records, which allows
   IPv6-only hosts to avoid local address synthesis.  If the IPv6-only
   hosts are not using DNSSEC, then it is enough if the network's DNS64 
   server returns synthetic AAAA resource records pointing to IPv4-only servers

   If the IPv6-only host has no other choice than use IPv4-address
   literals and perform local synthesis by using the discovered
   Pref64::/n, then the network ought to ensure with routing that the
   packets are delivered to the correct NAT64.  For example, a router in
   the path from IPv6-only host to NAT64s can forward the IPv6 packets
   to correct NAT64 as illustrated in Figure 2.  The routing could be
   based on the last 32-bits of the IPv6 address, but the network operator
   can also use some other IPv6 address format allowed by RFC 6052 [RFC6052],
   if it simplifies routing setup.

                       NAT64 "A" ----- IPv4-only servers in a datacenter
                      /
   IPv6-only host----router
                      \
                       NAT64 "B" ----- IPv4 Internet

                  Figure 2: NAT64s with Assisting Router
-----end--------

Some comments also inline.

Best regards,

Teemu

> From: ext Dmitry Anipko [mailto:[email-masked]]
> Sent: 28. kesäkuuta 2012 03:14
> To: Savolainen Teemu (Nokia-NRC/Tampere); Dave Thaler; [email-masked]
> If there are use cases for draft-ietf-behave-nat64-discovery-heuristic-09, same
> use cases if they make sense in e.g. enterprise network using RFC 1918
> addresses, in such network will result in 10.* literals. Do use cases of draft-
> ietf-behave-nat64-discovery-heuristic-09 apply to enterprise networks (or
> homenet) or other networks, which have legacy parts using RFC 1918 space?
> E.g. a network which has new IPv6-only segment, and some legacy
> segment/servers with IPv4 addressing, to which IPv6 only can only connect
> using DNS64/NAT64?

We have not limited this to particular deployments or ruled scenarios out. Please see above text that ought to help. I.e., in a network that has IPv6-only segment, it would be wise to have proper AAAA records also for the IPv4-only servers, not use DNSSEC, or have routing system assisting as described.

> If people are deploying such configurations, and there is a way to make them
> work without breaking connectivity, then the only consideration is whether it
> is acceptable to require that the network which the node visits needs to be re-
> configured in order for the node to be able to use the heuristic. If it is
> acceptable, I think the text you proposed would benefit if it is elaborated how
> the network shall be designed to handle this case, but otherwise it looks good
> to me.

There should now be proposal on how the network should be designed to work with this tool.

I do not think it is a tough requirement to require network reconfiguration (e.g. routing, or DNS records to be created), as currently IPv6-only hosts would not be able to connect there at all (due lack of prefix discovery and local synthesis capability). 

Maybe in some networks, e.g. enterprise with tight administration frameworks and IPv4-only pockets, it might also be useful to be able to deliver detailed mapping rules to hosts, but I would assume in such scenarios some other administrative protocols could be used?

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 28 Jun 2012 07:47:58 +0000

> environment, and applications using these protocols are generally not run

In the case of SIP, once the client gets IPv4 addresses with SDP, the client can then synthesize (set of) IPv6 addresses and use them as candidate addresses alongside other candidate addresses, right? The ICE procedure will then tell if (some of) the synthetic addresses yields in working connection or not.

Hence especially for SIP/ICE-using apps we do not need any dedicated connectivity check servers as the connectivity check system is already inbuilt with ICE, right?

Best regards,

        Teemu

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 28 Jun 2012 07:55:34 -0700

> Hence especially for SIP/ICE-using apps we do not need any dedicated connectivity check servers as the connectivity check system is already inbuilt with ICE, right?

You are right.

- -- 
Marc Petit-Huguenin

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Jun 2012 10:39:52 -0700

> Sent: Wednesday, June 27, 2012 11:49 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> I think that is what we should do - the heuristic will not discover
> these mappings, and the ISP should configure their networks so that the
> impact is minimal - see below about this.
> 
> But how many IPv4 prefixes there are... 4 billion queries to learn
> mapping for all 2^32 possible /32 destinations ranges?-)
> 
> devices, one
> This mapping of IPv4 address ranges to IPv6 addresses problem for
> heuristics only in the case of NAT64 being close to the IPv6 host?
> Right?

Yes.

> In the above example, if the setup is static, I would suggest ISP to
> create signed AAAA records for the IPv4-only servers in the datacenters
> (using Pref64::/n of the NAT64 above), in which case the IPv6-only
> DNSSEC using host would get signed AAAA response from the DNS, and
> would use that (no need for local synthesis). I.e. from host point of
> view it would be talking to "real" IPv6 destination.
> 
> Also, in the case of non-DNSSEC using IPv6-only host, it is enough that
> ISP's DNS64 returns synthetic AAAA records for the servers in
> datacenter.
> 
> Now in case the ISP does not want to provide signed AAAA records for
> the servers in data center, but host does DNSSEC validation (or
> otherwise gets IPv4 literal), then the packets from the host could end
> up using Pref64::/n of the below NAT64, and packets would be sent using
> "incorrect" Pref64::/n. However, in case of ISP, why the ISP could not
> have more specific routes that would ensure the packets host sends to
> Pref64_of_below_NAT64:IPv4addressofdatacenter would be actually routed
> to the above NAT64, and not to Internet-leading NAT64? .. . and I
> notice this is what you propose below:)
> 
> be needed
> But generally I would even more prefer for ISP to ensure the IPv6-only
> host does not get IPv4 address literal for its servers in datacenters,
> but instead provides signed AAAA records for those servers.

Sure.

But we're stuck with IPv4 address literals with SIP, XMPP, and other
protocols.

-d

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 29 Jun 2012 03:39:59 +0000

Thanks Teemu & Dan for clarifications and suggested text. I have 3 comments:

1. Is this a realistic recommendation for data center operators to create signed records for thousands of synthesized addresses of IPv4 only hosts? E.g., are there tools which allow to do that easily and easily update in case of network renumbering or new hosts being deployed dynamically? 

2. I agree with you that a scenario with 2 NAT64 and shared IPv6 prefix can be solved by routing based on prefix which includes the IPv4 ranges bits. But my original question was somewhat different - what if there are NAT64 and they serve different IPv4 address ranges, mapped to *different* Pref64/n. 

I don't yet see how routing alone helps there. Perhaps I'm missing something, so let me give an example - let's say the mappings table is A4_1 -> Pref64_1/n (for NAT64_1, path to Internet), A4_2 -> Pref64_2/n (for NAT64_2, path to datacenter), and heuristic for a packet destined to A4_1 incorrectly formed Pref64_2:A4_1 as IPv6 destination address.

If the IPv6 network has only Pref64_1/n and Pref64_2/n routes, then such packet Pref64_2:A4_1 will be routed to NAT64_2, which either will drop the packet (if it verifies that IPv4 is in the allowed range for the used IPv6 prefix), or will translate it to A4_1, and send packet destined to Internet into datacenter network, that may not go anywhere.

If the network has also Pref64_2:A4_1 -> NAT64_1 route, to compensate for heuristic lack of support of mappings, such route will bring the packet to NAT64_1, but again, unless NAT64_1 has a configuration for route Pref64_2, NAT64_1 will not know how to translate Pref64_2:A4_1 -> A4_1 and may drop the packet.

So is the assumption/suggestion that in addition to routing which include IPv4 ranges bits, all NAT64s are configured with shared configuration, so that they know about each other prefixes? Or the assumption is that one would never want to have Pref64_2 != Pref64_1, and just one shared Pref64 is sufficient always?

3. If the heuristic is a documented kludge - what are the reasons it is put on the standards track instead of informational/experimental?

Thank you,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 28, 2012 1:31 AM
To: Dmitry Anipko; Dave Thaler; [email-masked]
Subject: RE: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-09

Hi Dmitry,

-----end--------

Best regards,

Teemu

Best regards,

Teemu