Subject: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01

From: Washam Fan <[email-masked]>
Date: Sat, 2 Oct 2010 21:49:53 +0800

Hi,

It says:

   A host requiring information for local IPv6 address synthesis or
   NAT64 avoidance shall send a DNS query for AAAA record of a well-
   known IPv4-only fully qualified domain name.

How does a host know a existing well-known IPv4-only FQDN? Should this
FQDN be pre-configured and if yes, how?

I know there are several alternatives for host-based synthesis and
DNS64 avoidance in DS environment. Is there any concrete plan on these
issues in the WG? Would we work out a standard way to address these
issues?

Thanks,
washam

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Oct 2010 11:44:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Washam Fan
> Sent: Saturday, October 02, 2010 6:50 AM
> To: [email-masked]
> Subject: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01
> 
> Hi,
> 
> It says:
> 

DHCPv6 or static configuration (e.g., "ipv4-only.ip6.arpa").

> issues in the WG? Would we work out a standard way to address these

Yes.  In "BEHAVE status, call for document help"
http://www.ietf.org/mail-archive/web/behave/current/msg08848.html,
I wrote:

[...]
#  "Apr 2011            Submit to IESG: avoiding NAT64 with dual-stack
#   host for local networks (std)"
#
#This is related to the presentation in Maastricht titled "Analysis:
#hosts knowing AAAA is synthesized versus hosts creating their own
#synthesized", by Jouni Korhonen and Teemu Savolainen,
#http://www.ietf.org/proceedings/78/slides/behave-1.pdf and the
#following mechanisms that were compared:
#       Section 4.1 of draft-wing-behave-learn-prefix-04
#       Section 4.2 of draft-wing-behave-learn-prefix-04
#       Section 3.3 of draft-wing-behave-learn-prefix-03
#       draft-korhonen-edns0-synthesis-flag-00
#       Section 3 of draft-korhonen-edns0-synthesis-flag-00
#       Section 4 of draft-korhonen-edns0-synthesis-flag-00
#       draft-boucadair-behave-dns64-discovery-00
#
#The working group needs to decide (A) which scenarios are important to
#be solved and (B) which solution solves those scenarios.
#
#It would be valuable for someone to volunteer to write an Internet
#Draft discussing the scenarios and then discussing the applicability
#of each of the 7 mechanisms to solving the scenarios.

After I sent that mail, Temmu Savolainen and Jouni Korhonen volunteered.

-d

---

From: Christian Huitema <[email-masked]>
Date: Mon, 4 Oct 2010 19:36:10 +0000

Dan,

I suppose your comment now applies to draft-savolainen-heuristic-nat64-discovery-00. The draft describes a heuristic for discovering the local NAT64, and the prefix used for address translation -- WKP or NSP. The draft does so by performing a "DNS query to a well-known IPv4 only domain name." 

My main objection to this is the reliance on DNS for discovering network connectivity information. This will fail if the NAT64 does not operate a DNS64 translator, or if the local host gets its addresses from a different DNS server than the one tied to the NAT64, e.g. something like Open DNS.

Did the authors look at using STUN, or a variant of STUN, to perform this heuristic discovery?

-- Christian Huitema

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 4 Oct 2010 12:49:18 -0700

> My main objection to this is the reliance on DNS for discovering network connectivity information. This will fail if the NAT64 does not operate a DNS64 translator, or if the local host gets its add…

If the clients are in an IPv6-only network and using OpenDNS to
connect to IPv4 hosts on the Internet, they will be pretty broken in
any event.  I think this draft provides a reasonable assumption that
the host can work in a "sane" environment where the client, NAT64, and
DNS64 are configure to work together correctly.

Or, if the user is dual stack and not using the DNS64, they will
unlikely traverse the NAT64.

> Did the authors look at using STUN, or a variant of STUN, to perform this heuristic discovery?

I believe the solution as proposed in lightweight enough to be useful,
it only requires software on the IPv6 client an FQDN.  I believe this
model will fit well with the network i have today.  I would rather not
have to deploy a STUN server for this purpose.

Cameron

---

From: <[email-masked]>
Date: Mon, 4 Oct 2010 22:41:22 +0200

Christian,

As Cameron put it, someone would have to run a STUN server. If one has STUN server available, yes, why not.

The idea behind this draft is to describe the lightest solution possible and one that does not require new elements on the network (to access networks or to the server side). I think this could be implemented e.g. in a browser that wishes to increase its chances of success when encountering IPv4 literals in IPv6-only networks, or e.g. by a DNS resolver service in an OS. Introducing STUN would require that someone would have to operate it and it would introduce additional protocol into play (e.g. support to browser/OS).

The DNS approach would probably also allow some level of caching (in a host or in a recursive DNS server) hence generating less traffic.

The I-D is Informational (for now) as the lightweight solution should not require any standards work:) (If IANA would define a well-known name should it then be STD?) The other, more explicit and more reliable, proposals are then the ones that require something from the infrastructure (and are for STD).

Best regards,

Teemu

> Behalf Of ext Christian Huitema
> Sent: 04. lokakuuta 2010 22:36
> To: Dan Wing; 'Washam Fan'; [email-masked]
> Subject: Re: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> Dan,
> 
> I suppose your comment now applies to draft-savolainen-heuristic-nat64-
> discovery-00. The draft describes a heuristic for discovering the local
> NAT64, and the prefix used for address translation -- WKP or NSP. The
> draft does so by performing a "DNS query to a well-known IPv4 only
> domain name."
> 
> My main objection to this is the reliance on DNS for discovering
> network connectivity information. This will fail if the NAT64 does not
> operate a DNS64 translator, or if the local host gets its addresses
> from a different DNS server than the one tied to the NAT64, e.g.
> something like Open DNS.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Oct 2010 14:17:13 -0700

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, October 04, 2010 12:36 PM
> Subject: RE: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> Dan,
> 
> discovery-00.	

Cameron suggested that the WG might want to consider only supporting 
96 bit prefixes.  My comment is that we need to support any of
the prefixes defined in the Address Format document, including all 
of the prefix lengths allowed in that document.

> The draft describes a heuristic for discovering the local

Unless you have some different deployment model that I cannot
diagram in my head, an IPv6-only host pointing at an OpenDNS 
server would only be able to access an IPv4-only server if
(a) the OpenDNS server is also operating as a DNS64 and (b)
its synthesized AAAA records point towards a NAT64 that translates
IPv6 packets to IPv4 packets for that user.  If either (a)
or (b) is not true, the IPv6-only host will not be able to
access IPv4-only servers using normal, unmodified, NAT64-friendly
applications (IMAP, POP, etc.).

I imagine such a service will exist.  And such a service will work 
with draft-savolainen-heuristic-nat64-discovery.

-d

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Oct 2010 11:00:04 +0200

Hi Teemu.

1.
Isn't the format of the proposed option a subject that needs standardization? (See (*) below.)

2.
An alternative could be a DHCP option that provides the "NAT64 prefix" (the WKP or NSP prefix used by NAT64s to synthesize IPv6 addresses of external IPv4 hosts). It could IMHO coexist with the DNS based solution of draft-korhonen to facilitate deployments where DHCP servers are easier to upgrade than DNS servers. 

3.
In hosts that access Internet via IPv6-only-routing networks, knowing the NAT64 prefix is indeed useful to synthesize IPv6 addresses of IPv4 referrals, as indicated in the draft. But it also permits hosts to recognize which incoming connections were originated by IPv4-only remote hosts. This permits to present them as IPv4 connections as the socket API. 

Point 3, is IMHO a simple approach to eliminate conflicts between NAT64s and IPv4-only or dual-stack applications.  

Regards,
RD   

Le 4 oct. 2010 à 22:41, <[email-masked]> <[email-masked]> a écrit :
> ...

> The I-D is Informational (for now) as the lightweight solution should not require any standards work:)

(*)

> (If IANA would define a well-known name should it then be STD?) The other, more explicit and more reliable, proposals are then the ones that require something from the infrastructure (and are for STD).
> 
> Best regards,
> 
> Teemu
>

---

From: <[email-masked]>
Date: Tue, 5 Oct 2010 12:25:50 +0200

Rémi,

> standardization? (See (*) below.)

Definitely, but the draft-savolainen- is not proposing any new options (just methods one could implement without IETF involved). Draft-korhonen- is proposing new ENDS0 option and that of course requires standardization.

> 2.
> An alternative could be a DHCP option that provides the "NAT64 prefix"
> (the WKP or NSP prefix used by NAT64s to synthesize IPv6 addresses of
> external IPv4 hosts). It could IMHO coexist with the DNS based solution
> of draft-korhonen to facilitate deployments where DHCP servers are
> easier to upgrade than DNS servers.

Yes, we are writing an analysis draft that should cover all proposed ways to solve the problem (was it 7 or 8 different already), after which it should be easier to discuss pros and cons of each.

> 3.
> In hosts that access Internet via IPv6-only-routing networks, knowing
> the NAT64 prefix is indeed useful to synthesize IPv6 addresses of IPv4
> referrals, as indicated in the draft. But it also permits hosts to
> recognize which incoming connections were originated by IPv4-only
> remote hosts. This permits to present them as IPv4 connections as the
> socket API.

True, but I believe that scenario is out of behave's scope. But if we forget socket API and apparent double translation for incoming connections, it might be still useful for some IPv6-enabled application to be aware of that.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Tue, 5 Oct 2010 14:07:04 +0200

Dear Rémi, all,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : mardi 5 octobre 2010 11:00
À : [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01

Hi Teemu.

1.

2.

3.

Med: This approach can be useful to avoid a NAT64 only if the NAT64 is located in the same domain as the IPv6 client. Please refer to http://tools.ietf.org/html/draft-xu-behave-hybrid-type-prefix-00#section-1.1 for more details. Note that referrals will fail if the synthesised IPv6 address does not belong to the same domain as the IPv6-only host.
FWIW, a DHCPv6 option to provision an IPv6-enabled host with an IPv6 prefix and a format to use when synthesising an IPv4-Converted IPv6 address is described in http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-01#section-4 (this option has been defined for encapsulation schemes where we don't have the referral issue. New format type values can be defined according to the behave address format ID).

Regards,
RD   

(*)

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Oct 2010 14:08:44 +0200

> Yes, we are writing an analysis draft that should cover all proposed ways to solve the problem (was it 7 or 8 different already), after which it should be easier to discuss pros and cons of each.

It will be welcome.
 
> True, but I believe that scenario is out of behave's scope.

Behave should IMHO be concerned with the need to provide mechanism whereby hosts recognize which incoming IPv6 connections are in fact IPv4 connections (IPv4-only originated).

If not in Behave, where this issue would fit isn't clear to me.

> But if we forget socket API and apparent double translation for incoming connections,
> it might be still useful for some IPv6-enabled application to be aware of that.

The "apparent double translation" is in fact only a translation "of addresses". IPv4 payloads need not to be looked at.

An application that has IPv6 enabled and is interested in recognizing addresses that are those of IPv4-only remote hosts could IMHO be viewed as a particular case of dual-stack application (IPv6 AND IPv4 aware).

Would you agree? 

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Oct 2010 15:58:24 +0200

Hi Med,

Comment below.

Le 5 oct. 2010 à 14:07, <[email-masked]> a écrit :
> Med: This approach can be useful to avoid a NAT64 only if the NAT64 is located in the same domain as the IPv6 client.

Well, this approach isn't really to "avoid" NAT64, it is rather to improve IPv4 connectivity across them.
It doesn't concern scenarios where it is useful to know whether remote ISPs operate 64s or not.

The question at hand is only "If an ISP only routes IPv6 and supports NAT64/DNS64, what should it provide to its customers for IPv4 connectivity to be good enough." 

Different considerations apply to incoming and outgoing host connections.

An INCOMING connection via a NAT64 implies that the NAT64 maps some IPv4 address (or address + port prefix, or address + port) to the host IPv6 address. The mapping may be static or the result of some hole punching in the NAT, but it has to preexist. 
If the host knows the IPv6 prefix used in its local-ISP NAT64,  it can recognize which incoming connections come from IPv4-only hosts, and use that information. 

For an OUTGOING connection to an IPv4-only host:
- If its destination address is obtained from the DNS, the local DNS64 has synthesized the address. Knowing the NTA64 prefix of its local ISP, the host can determine that the destination is IPv4-only.
- If the destination address is NOT obtained from the DNS, it has, to be made in the same way to all hosts, to be an IPv4 referral. It can be locally translated to an IPv6 destination by prepending to it the NTA64 prefix of its local ISP (a point of draft-korhonen).

Are there other important NAT64 scenarios for the v4tov6transition?
Not in my understanding, but an explanation of what would be missing would of course be welcome.

Kind regards,
RD

> Please refer to http://tools.ietf.org/html/draft-xu-behave-hybrid-type-prefix-00#section-1.1 for more details. Note that referrals will fail if the synthesised IPv6 address does not belong to the same domain as the IPv6-only host.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Oct 2010 10:29:35 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2010 5:07 AM
> To: Rémi Després; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Med: This approach can be useful to avoid a NAT64 only if the NAT64 is
> located in the same domain as the IPv6 client.

I don't understand what you're referring to when you say "this approach" --
is that referring to only (3)?  Or to 1, 2, and 3?

I also don't understand what is meant by 'same domain of the IPv6 client',
specifically the phrase 'same domain'.  Let's consider a DNS64 and NAT64
operated by some entity on the Internet as a service, such as operated 
SixXS (for example) or operated by alumni.example.edu.  I chose those
examples because it is clear that DNS64 and NAT64 is not operated by
the same Internet Service Provider that is providing IPv6-only access
service to the IPv6-only host.

Are those services in the same domain as the IPv6-only client?

Does the BEHAVE working group consider those NAT64+DNS64 services
in scope?  Or important to consider when evaluating a solution?

-d

> Please refer to
> http://tools.ietf.org/html/draft-xu-behave-hybrid-type-prefix-
> 00#section-1.1 for more details. Note that referrals will fail if the
> synthesised IPv6 address does not belong to the same domain as the
> IPv6-only host.
> FWIW, a DHCPv6 option to provision an IPv6-enabled host with an IPv6
> prefix and a format to use when synthesising an IPv4-Converted IPv6
> address is described in http://tools.ietf.org/html/draft-boucadair-
> dhcpv6-shared-address-option-01#section-4 (this option has been defined
> for encapsulation schemes where we don't have the referral issue. New
> format type values can be defined according to the behave address
> format ID).
> 
> Point 3, is IMHO a simple approach to eliminate conflicts between
> NAT64s and IPv4-only or dual-stack applications.
> 
> Regards,
> RD
> 
> 
> 
> 
> > The idea behind this draft is to describe the lightest solution
> possible and one that does not require new elements on the network (to
> access networks or to the server side). I think this could be
> implemented e.g. in a browser that wishes to increase its chances of
> success when encountering IPv4 literals in IPv6-only networks, or e.g.
> by a DNS resolver service in an OS. Introducing STUN would require that
> someone would have to operate it and it would introduce additional
> protocol into play (e.g. support to browser/OS).
> >
> > The DNS approach would probably also allow some level of caching (in
> a host or in a recursive DNS server) hence generating less traffic.
> 
> > (If IANA would define a well-known name should it then be STD?) The
> other, more explicit and more reliable, proposals are then the ones
> that require something from the infrastructure (and are for STD).
> >
> > Best regards,
> >
> > Teemu
> >

---

From: <[email-masked]>
Date: Tue, 5 Oct 2010 20:02:17 +0200

Dear Dan, all,

Apologies for the confusion.

I used "domain" to denote an administrative network domain (also called an Autonomous System).

Cheers,
Med

________________________________________
De : Dan Wing [[email-masked]]
Date d'envoi : mardi 5 octobre 2010 19:29
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Rémi Després'; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: [BEHAVE] One comment on draft-korhonen-edns0-synthesis-flag-01

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Oct 2010 11:12:14 -0700

> Sent: Tuesday, October 05, 2010 11:02 AM
> To: Dan Wing; 'Rémi Després'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE : [BEHAVE] One comment on draft-korhonen-edns0-synthesis-
> flag-01
> 
> Dear Dan, all,
> 

As in, a BGP AS?

So, you are suggesting we (BEHAVE) should not concern itself with a
DNS64+NAT64
operated by an entity other than the ISP providing IPv6-only network
connectivity.

-d

> > > The I-D is Informational (for now) as the lightweight solution
> should
> > not require any standards work:)
> >
> > (*)
> >
> > >> Did the authors look at using STUN, or a variant of STUN, to
> perform
> > >> this heuristic discovery?
> > >>
> > >> -- Christian Huitema
> > >>
> > >>
> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.

---

From: <[email-masked]>
Date: Wed, 6 Oct 2010 08:05:33 +0200

Re-,

Please see inline.

Cheers,
Med
Date d'envoi : mardi 5 octobre 2010 20:12

As in, a BGP AS?

Med: Yes.

Med: My answer may be biased because I'm part of those who proposed solutions to cover the scenario where the NAT64 responsible for generating the IPv4-Converted IPv6 address and the IPv6 host are not attached to the same network domain. At least three solutions cover this use case: edns0 flag, A64 RR and the HTP. IMHO, this discussion can be part of the analysis I-D you asked for in an earlier e-mail.