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

From: <[email-masked]>
Date: Sun, 10 Jul 2011 17:04:57 +0000

Hi,

Referring to discussions we had couple of days ago in this list; here is an update for the non-standard NSP considerations (essentially saying they are out of scope of the draft, and removing the corresponding section).

Teemu
________________________________________
From: [email-masked] [[email-masked]] on behalf of ext [email-masked] [[email-masked]]
Sent: Sunday, July 10, 2011 1:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [BEHAVE] I-D Action:   draft-ietf-behave-nat64-discovery-heuristic-02.txt

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

        Title           : Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name
        Author(s)       : Teemu Savolainen
                          Jouni Korhonen
        Filename        : draft-ietf-behave-nat64-discovery-heuristic-02.txt
        Pages           : 8
        Date            : 2011-07-10

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

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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-02.txt
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Jul 2011 19:34:21 +0000

The text looks good now. 

I still have some reservation about having all hosts use the same "well-known" name. Anything well known exposes the host to abuse by intermediaries, e.g. gateways or firewalls who perform "special processing" of the well-known name. It would be nice to have some text somewhere saying that developers can program any name and address of their liking, as long as the name as the same properties as the well-known name, e.g. only exposes IPv4 addresses.

In fact, the draft mentions that "The host MUST NOT perform connectivity test for the well-known IPv4 address of the well-known name, but instead to some other destination such as host vendor servers." If that is the case, why not rely solely on host vendor servers, including for the discovery?

I could see something like:

1) Resolve "my-vendor-ipv4-only.com";
2) Send a request to the host, "please tell me the IPv4 address through which you received this."
3) If the reply is received, compare the IPv4 address value returned by the host to the IPv6 address used to send the request, perform the heuristics, discover the prefix. 

That could actually be done using STUN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, July 10, 2011 10:05 AM
To: [email-masked]
Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-02.txt

Hi,

Teemu

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 13:43:42 +0000

Hi,

Well.. it seems well-known/vendor specific names is tradeoff to decide on. Maybe there will be further opinions/discussion on behave WG session?

The connectivity test is not mandatory, it depends. For example a web browser seeing IPv4 literal may not need to do any connectivity test, but just try to connect via locally synthesized IPv6 address and succeed or fail. I wrote the connectivity test to well-known name should not be made as it might invite too much traffic to party hosting the name.

I agree STUN could be used/enhanced for the detection, but it requires use of STUN and especially in simpler cases that probably is not available.

Best regards,

	Teemu

> From: ext Christian Huitema [mailto:[email-masked]]
> Sent: 10. heinäkuuta 2011 22:34
> To: Savolainen Teemu (Nokia-CTO/Tampere); [email-masked]
> Subject: RE: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-
> 02.txt
> 
> The text looks good now.
> 
> I still have some reservation about having all hosts use the same "well-known"
> name. Anything well known exposes the host to abuse by intermediaries, e.g.
> gateways or firewalls who perform "special processing" of the well-known
> name. It would be nice to have some text somewhere saying that developers
> can program any name and address of their liking, as long as the name as the
> same properties as the well-known name, e.g. only exposes IPv4 addresses.
> 
> In fact, the draft mentions that "The host MUST NOT perform connectivity test
> for the well-known IPv4 address of the well-known name, but instead to some
> other destination such as host vendor servers." If that is the case, why not rely
> solely on host vendor servers, including for the discovery?
> 
> 3) If the reply is received, compare the IPv4 address value returned by the host
> to the IPv6 address used to send the request, perform the heuristics, discover
> the prefix.
> 
> Referring to discussions we had couple of days ago in this list; here is an update
> for the non-standard NSP considerations (essentially saying they are out of
> scope of the draft, and removing the corresponding section).
> 
> Teemu
> From: [email-masked] [[email-masked]] on behalf of ext
> [email-masked] [[email-masked]]
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance Avoidance
> Working Group of the IETF.
>

---

From: "Yi Ding(Aaron)" <[email-masked]>
Date: Tue, 26 Jul 2011 18:47:06 +0300

Hi,

Concerning the vendor specific names, there is a statement in
Section 8.1

"A global address is required as otherwise DNS64 entity
will not perform AAAA record synthesis. The address does
not have to be routable as no communications are initiated
to the IPv4 address."

This somehow restricts the developers to play with any name or
address of their liking, especially on host vendor servers with
local visibility to DNS64.

According to previous tests with ecdysis-DNS64, if such IPv4 address
and v4-only names exist in local DB instead of global, DNS64 simply
bypasses the AAAA synthesis. Not sure whether such behaviors appear on
other implementations or not. but this certainly posts a limitation.
The well-known names approach is better in this aspect although it does
not solve all the issues.

-- Aaron