Subject: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 15:15:24 +0000

I have two main technical comments, and a bunch of smaller mostly editorial comments.

The main technical comments are that I think it's missing a discussion of two key requirements:

1)      Need support for applications that don't use DNS (e.g., ones that get IP literals via an application layer referral)

2)      Need ability to learn multiple prefixes, not just one (NAT64 and DNS64 docs say there can be one or more prefixes).   This even affects the title of the document.

As such, I disagree with the conclusions since the "recommended" ones don't actually meet
the requirements in my view.

A marked up comment with my full comments can be found at
http://research.microsoft.com/~dthaler/draft-korhonen-behave-nat64-learn-analysis-00.pdf

-Dave

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 10 Nov 2010 07:42:54 -0800

On 11/10/2010 7:15 AM, Dave Thaler wrote:
> 1)Need support for applications that don't use DNS (e.g., ones that 
> get IP literals via an application layer referral)
>
> 2)Need ability to learn multiple prefixes, not just one (NAT64 and 
> DNS64 docs say there can be one or more prefixes).   This even affects 
> the title of the document.
>

Agree 100% with this. Support for applications that do not and can not 
use DNS is mandatory. Support for learning multiple prefixes is probably 
a requirement as well.

> <http://research.microsoft.com/%7Edthaler/draft-korhonen-behave-nat64-learn-analysis-00.pdf>
>

Largely agree with this markup. A few comments specific to it:

DT22 points out a big issue regarding the difference between "learning a 
prefix" and "learning a prefix *and* the derivation algorithm". Not sure 
about comment DT26... why can't multiple AAAA records be returned as a 
reply, assuming that the DNS64 knows about all the NAT64 it covers?

On DT35, while DHCP servers can configure any DHCP option, there are 
cases where a single static entry for a particular option is not 
sufficient (see, for instance, how vendor encapsulated options need to 
work at the server side)... one could imagine similar issues with 
providing a WKP.

Matthew Kaufman

---

From: <[email-masked]>
Date: Wed, 10 Nov 2010 17:24:26 +0100

Hi,

Thank you for feedback. Some clarifying questions

1)      Do you mean such applications cannot even do single DNS query just for learning the NSP (DNS-less host?)? Even if after that they could continue their non-DNS using procedures? What could they do then?

2)      This sounds like a very hard problem, as how can you possibly tell how many NAT64s there are in an access network? Maybe by downloading some kind of a NAT64 table from network (with DHCPv6?) ? For the case access network does not support discovery of NAT64s with any explicit means, what else host can do than maybe query dozen names (with significantly different IPv4-only addresses) and then live with the NSPs obtained with such an attempt? (send more than two hundred A queries for each /8 subnet in existence?-)

Suggestions for better than the proposed ones are also welcome. For both cases: network assisted and without network assistance.

Teemu

From: ext Matthew Kaufman [mailto:[email-masked]]
Sent: 10. marraskuuta 2010 23:43
To: Dave Thaler
Cc: 'behave' ([email-masked]); [email-masked]
Subject: Re: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00

Agree 100% with this. Support for applications that do not and can not use DNS is mandatory. Support for learning multiple prefixes is probably a requirement as well.

A marked up comment with my full comments can be found at
http://research.microsoft.com/~dthaler/draft-korhonen-behave-nat64-learn-analysis-00.pdf<http://research.microsoft.com/%7Edthaler/draft-korhonen-behave-nat64-learn-analysis-00.pdf>

DT22 points out a big issue regarding the difference between "learning a prefix" and "learning a prefix *and* the derivation algorithm". Not sure about comment DT26... why can't multiple AAAA records be returned as a reply, assuming that the DNS64 knows about all the NAT64 it covers?

On DT35, while DHCP servers can configure any DHCP option, there are cases where a single static entry for a particular option is not sufficient (see, for instance, how vendor encapsulated options need to work at the server side)... one could imagine similar issues with providing a WKP.

Matthew Kaufman

---

From: <[email-masked]>
Date: Wed, 10 Nov 2010 17:27:04 +0100

Sorry more than two hundred AAAA queries for names that have only A record and each addressed from different /8 :)

(ipv4-only-net1.corp.com (1.0.0.1), ipv4-only-net2.corp.com (2.0.01), ipv4-only-net3.corp.com (3.0.0.1) ..... )

1)      such an attempt? (send more than two hundred A queries for each /8 subnet in existence?-)

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 10 Nov 2010 09:40:43 -0800

On 11/10/2010 8:24 AM, [email-masked] wrote:
> 1)Do you mean such applications cannot even do single DNS query just 
> for learning the NSP (DNS-less host?)? Even if after that they could 
> continue their non-DNS using procedures? What could they do then?
>
I'm ok with a single DNS query (in fact, I don't see any other good 
solution that I can use as an app developer who can't change the OS I'm 
running on), but it needs to be sufficient to calculate all future 
mappings... so I need to get prefix and (if necessary) the algorithm by 
which the bottom part is computed this way.
>
> 2)This sounds like a very hard problem, as how can you possibly tell 
> how many NAT64s there are in an access network? Maybe by downloading 
> some kind of a NAT64 table from network (with DHCPv6?) ? For the case 
> access network does not support discovery of NAT64s with any explicit 
> means, what else host can do than maybe query dozen names (with 
> significantly different IPv4-only addresses) and then live with the 
> NSPs obtained with such an attempt? (send more than two hundred A 
> queries for each /8 subnet in existence?-)
>
One would hope that your DNS64 knows about all your NAT64 options. The 
problem of course is when it tries to be smart, and give you different 
NAT64 based on things like where the IPv4 traffic is going.
>
> Suggestions for better than the proposed ones are also welcome. For 
> both cases: network assisted and without network assistance.
>
My present best suggestion is to force the application to make a AAAA 
query for <ipv4-literal>.<magic-suffix> for every single address. Pretty 
easy to tell if your DNS server is answering those, and once it is it 
probably isn't that hard to do a query for every v4 literal you might 
need to use. It solves the algorithm problem as well as the 
multiple-exits problem., but requires nothing additional that the app 
might not be able to change. It changes the title from "Proposal for 
hosts to learn NAT64 prefix" to "Proposal for hosts to learn 
NAT64-mapped address".

In short, instead of asking for the AAAA for 
"what-is-my-NAT64-prefix.arpa" you would ask for the AAAA for 
"192.0.2.1.is-there-a-NAT64-mapping.arpa" for every single literal you 
need translated.

Matthew Kaufman

---

From: jouni korhonen <[email-masked]>
Date: Wed, 10 Nov 2010 19:49:00 +0200

Hi Dave,

Thanks for the review. See some initial comments inline.

On Nov 10, 2010, at 5:15 PM, Dave Thaler wrote:

> The main technical comments are that I think it’s missing a discussion of two key requirements:
> 1)      Need support for applications that don’t use DNS (e.g., ones that get IP literals via an application layer referral)

Right. However, most hosts use DNS at some point of time and eventually applications in the host, even those not themselves using DNS, could learn the synthesized prefixes (assuming there were a way for applications to ask for synthesized prefixes known to the host). Using some kind of host wide repository would introduce additional issues though..

> 2)      Need ability to learn multiple prefixes, not just one (NAT64 and DNS64 docs say there can be one or more prefixes).   This even affects the title of the document.

Do you mean that none of the analyzed proposals work if a single DNS response from DNS64 would contain multiple AAAA RRs and each had a different Pref64::/n ? Most if not all of the analyzed proposals actually seem to assume a single Pref64::/n at time. Some proposals do work if Pref64::/n changes e.g. between DNS responses.

>  
> As such, I disagree with the conclusions since the “recommended” ones don’t actually meet

Some comments.. excluding most of the editorials.

DT9: good point on the derivation algorithm. If the derivation algorithm is not documented, I wonder if there is anything we can do better than just learn the presence of the NAT64 for a given Pref64::/n..

DT14: correct. the bullet here is the same as the RFC3484 one.

DT17: We need to add a list of requirements as that is not currently there. We did not think this I-D as a requirements document.. which it in a way is though when it start comparing and recommending things. None of the listed DNS using proposals would actually meet the requirement stated in 1).

DT18: ok.

DT19: ok.

DT20: right.. but as said earlier, we did not have a list of requirements that the solutions would have to meet.

DT24: if well-known address is needed, one has to be written down somewhere. We had some discussion about it and the address could even be just a loopback address. I am not entirely sure whether such needs to be allocated from IANA.

DT27: ok.

DT27: ok. Will add the reference.

DT30: Well.. this is essentially the same as Section 4.10 proposal.. just that both solutions defined usable bits in a different format and the latter actually to a bit different context.

DT31: ok.

DT32: Original draft pay so much attention to it.. anyway, you are right. It does not really belong to this I-D.

DT33: Not all proposals would need a change in DNS server configuration, e.g. the ones discussed in Sections 4.1-3.

DT34: The assumption was that NAT64 and DNS64 has to be coordinated anyway. DHCP server would be additional to this.. but yes, agree with the comment.

DT35: Like ISC DHCP stuff also.. and still we considered this as a change. You need to add additional logic to your DHCP message handling as someone has to understand the new option.

DT36: Don't think so.. with mobiles the fact that huge amount of devices won't implement DHCP has an impact when making a decision between DHCP based solution vs. something else.

DT40: I guess if the DNS response contains multiple synthesized AAAA RRs, then the host would have to make the test against the STUN server with each of the received AAAAs. 

DT41: that was not the case e.g. with all DHCP software out there.

DT42: ok.

DT44: agree.

DT46: me neither ;) Need to ask Med about that.

DT47: ok.

DT49: agree.. still different I-Ds. This proposal was on the border of being cut away but stayed for the -00.

DT50-52: I'll leave these to Med.

DT53: I somewhat disagree, since this I-D did not have explicit requirement to begin with (which it should have had though).

DT54: An admin having a list of DNS servers he/she configures to the DHCP server does not need to know which is DNS64 and which is not.

DT55: hmm.. so basically the only method that every IPv6 capable host implements is NDP, which would mean the RA based solution would be the beauty contest winner here.

DT56: ok.

DT57: and SeND has been deployed.. ;)

Thanks. The review was rather intensive and really appreciated.

- Jouni

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 23:27:49 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of jouni korhonen
> Sent: Thursday, November 11, 2010 1:49 AM
> To: Dave Thaler
> Cc: [email-masked]; 'behave'
> ([email-masked])
> > 1)      Need support for applications that don't use DNS (e.g., ones that get IP
> literals via an application layer referral)
> 
> Right. However, most hosts use DNS at some point of time and eventually
> applications in the host, even those not themselves using DNS, could learn the
> synthesized prefixes (assuming there were a way for applications to ask for
> synthesized prefixes known to the host). Using some kind of host wide
> repository would introduce additional issues though..
> 
> 
> > 2)      Need ability to learn multiple prefixes, not just one (NAT64 and DNS64
> docs say there can be one or more prefixes).   This even affects the title of the
> document.
> 
> Do you mean that none of the analyzed proposals work if a single DNS response
> from DNS64 would contain multiple AAAA RRs and each had a different
> Pref64::/n ? Most if not all of the analyzed proposals actually seem to assume a
> single Pref64::/n at time. Some proposals do work if Pref64::/n changes e.g.
> between DNS responses.

It's possible some may support multiple prefixes in multiple DNS records returned.

Any proposal that only works with a single Pref64 at a time does not meet the
requirements in my view.   I believe there are several proposals in the doc that
do not make this assumption and would work with multiple prefixes.

-Dave

> 
> >
> > As such, I disagree with the conclusions since the "recommended" ones
> > don't actually meet the requirements in my view.
> >
> DT9: good point on the derivation algorithm. If the derivation algorithm is not
> documented, I wonder if there is anything we can do better than just learn the
> presence of the NAT64 for a given Pref64::/n..
> 
> DT17: We need to add a list of requirements as that is not currently there. We
> did not think this I-D as a requirements document.. which it in a way is though
> when it start comparing and recommending things. None of the listed DNS using
> proposals would actually meet the requirement stated in 1).
> 
> DT18: ok.
> 
> DT19: ok.
> 
> DT24: if well-known address is needed, one has to be written down somewhere.
> We had some discussion about it and the address could even be just a loopback
> address. I am not entirely sure whether such needs to be allocated from IANA.
> 
> DT27: ok.
> 
> DT30: Well.. this is essentially the same as Section 4.10 proposal.. just that both
> solutions defined usable bits in a different format and the latter actually to a bit
> different context.
> 
> DT31: ok.
> 
> DT34: The assumption was that NAT64 and DNS64 has to be coordinated
> anyway. DHCP server would be additional to this.. but yes, agree with the
> comment.
> 
> DT35: Like ISC DHCP stuff also.. and still we considered this as a change. You
> need to add additional logic to your DHCP message handling as someone has to
> understand the new option.
> 
> DT36: Don't think so.. with mobiles the fact that huge amount of devices won't
> implement DHCP has an impact when making a decision between DHCP based
> solution vs. something else.
> 
> DT40: I guess if the DNS response contains multiple synthesized AAAA RRs, then
> the host would have to make the test against the STUN server with each of the
> received AAAAs.
> 
> DT53: I somewhat disagree, since this I-D did not have explicit requirement to
> begin with (which it should have had though).
> 
> DT54: An admin having a list of DNS servers he/she configures to the DHCP
> server does not need to know which is DNS64 and which is not.
> 
> DT55: hmm.. so basically the only method that every IPv6 capable host
> implements is NDP, which would mean the RA based solution would be the
> beauty contest winner here.
> 
> DT56: ok.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 11 Nov 2010 08:29:55 +0800

----- 原邮件 -----
发件人: Dave Thaler <[email-masked]>
日期: 星期三, 十一月 10日, 2010 下午11:16
主题: [BEHAVE] Comments on draft-korhonen-behave-nat64-learn-analysis-00
收件人: "'behave' ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>

> 1)      Need support for applications that don't use DNS (e.g., 
> ones that get IP literals via an application layer referral)
> 
> 2)      Need ability to learn multiple prefixes, not just one 
> (NAT64 and DNS64 docs say there can be one or more prefixes).   
> This even affects the title of the document.

I fully agree with the above two points. 

Besides, I'm wondering how to support those applications that don't use DNS in the IPv6 Internet to IPv6 network scenario. Will the WKP be used in that case? However, this is conflicted with the following statement in RFC6052:

   "When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4-
   embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
   advertised in BGP (especially External BGP) [RFC4271] because this
   leads to importing the IPv4 routing table into the IPv6 one and
   therefore introduces scalability issues to the global IPv6 routing
   table.  Administrators of BGP nodes SHOULD configure filters that
   discard advertisements of embedded IPv6 prefixes longer than the
   Well-Known Prefix."

Do I miss something?

Best regards,
Xiaohu

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Nov 2010 02:39:52 +0200

HI,

> It's possible some may support multiple prefixes in multiple DNS records returned.

OK. This is a good point and unfortunately we missed that.

> do not make this assumption and would work with multiple prefixes.

There are several proposals that are capable of that technically, yes.. thought they do not really state that. Taking the multiple Pref64::/n requirement into account would actually change the outcome of the analysis quite a bit and no problem with that.

- Jouni

---

From: xuxiaohu 41208 <[email-masked]>
Date: Thu, 11 Nov 2010 09:12:54 +0800

----- 原邮件 -----
发件人: xuxiaohu 41208 <[email-masked]>
日期: 星期四, 十一月 11日, 2010 上午9:00
主题: Re: [BEHAVE] Comments on	draft-korhonen-behave-nat64-learn-analysis-00
收件人: Dave Thaler <[email-masked]>
抄送: "[email-masked]" <[email-masked]>, "'behave' ([email-masked])" <[email-masked]>

> 收件人: "'behave' ([email-masked])" <[email-masked]>, "draft-
> [email-masked]" <draft-
> [email-masked]>
> 
> > I have two main technical comments, and a bunch of smaller 
> mostly 
> > editorial comments.
> > 
> Besides, I'm wondering how to support those applications that 
> don't use DNS in the IPv6 Internet to IPv6 network scenario. Will 

Sorry, I'm saying IPv6 Internet to IPv4 network scenario.

Best regards,
Xiaohu

> the WKP be used in that case? However, this is conflicted with the 
> following statement in RFC6052:
> 
> > http://research.microsoft.com/~dthaler/draft-korhonen-behave-
> nat64-
> > learn-analysis-00.pdf
> > 
> > -Dave
> >

---

From: Jacni Qin <[email-masked]>
Date: Thu, 11 Nov 2010 09:40:36 +0800

Dear Jouni,

Another comment, the analysis of prefixes for multicast should be included
as well in the document.
Or did I miss it?

Cheer,
Jacni

On Thu, Nov 11, 2010 at 8:39 AM, jouni korhonen <[email-masked]>wrote:

> >>> I have two main technical comments, and a bunch of smaller mostly
> editorial
> >> comments.
> >>>
> >>> The main technical comments are that I think it's missing a discussion
> of two
> >> key requirements:
> There are several proposals that are capable of that technically, yes..
> thought they do not really state that. Taking the multiple Pref64::/n
> requirement into account would actually change the outcome of the analysis
> quite a bit and no problem with that.
>
> - Jouni
>
>
> >
> > -Dave
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Nov 2010 04:06:20 +0200

Hi,

On Nov 11, 2010, at 3:40 AM, Jacni Qin wrote:

> Dear Jouni,
> 
> Another comment, the analysis of prefixes for multicast should be included as well in the document.
> Or did I miss it?

Discovering the presence of a translator in general, the solutions for unicast vs. multicast should not make difference.. details may vary though. In order to differentiate prefix used for multicast translation and subsequent manual address synthesis the application then need to know the difference of learned prefixes. There is no specific text around this, yet.

- Jouni

> 
> 
> Cheer,
> Jacni
> 
> 
> 
> On Thu, Nov 11, 2010 at 8:39 AM, jouni korhonen <[email-masked]> wrote:
> HI,
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Nov 2010 13:06:24 +0800

> Besides, I'm wondering how to support those applications that don't use
> DNS in the IPv6 Internet to IPv6 network scenario. 

  Updated to:

  "I'm saying IPv6 Internet to IPv4 network scenario."

> Will the WKP be used in that case?

The NAT64 WKP is not a panacea -- an IPv6-only host cannot 
safely assume that there is a NAT64 using the WKP on its 
network.

-d

> However, this is conflicted with the following statement
> in RFC6052:
>

---

From: Jacni Qin <[email-masked]>
Date: Thu, 11 Nov 2010 14:29:42 +0800

hi,

On Thu, Nov 11, 2010 at 10:06 AM, jouni korhonen <[email-masked]>wrote:

> Discovering the presence of a translator in general, the solutions for
> unicast vs. multicast should not make difference.. details may vary though.
> In order to differentiate prefix used for multicast translation and
> subsequent manual address synthesis the application then need to know the
> difference of learned prefixes. There is no specific text around this, yet.
>

That's ok if we can use the same discovering method for both, but maybe a
statement to clarify that is needed somewhere.

Cheers,
Jacni

> > >>> The main technical comments are that I think it's missing a
> discussion of two
> > >> key requirements: