Subject: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Jan 2011 10:16:28 +0200

Folks,

Now citing a proper I-D ;-) We have (finally) updated the analysis I-D. Sorry that it took somewhat longer than planned. This version should address Dave's comments and the feedback we received in Beijing. Comments and feedback is solicited.

- Jouni

Begin forwarded message:

> From: [email-masked]
> Date: January 20, 2011 12:45:01 PM GMT+02:00
> To: [email-masked]
> Subject: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Analysis of solution proposals for hosts to learn NAT64 prefix
> 	Author(s)       : J. Korhonen, T. Savolainen
> 	Filename        : draft-korhonen-behave-nat64-learn-analysis-01.txt
> 	Pages           : 25
> 	Date            : 2011-01-20
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Jan 2011 09:10:21 -0500

I'm very happy to see that this new version addresses the issue of
multiple prefixes. Here are some specific comments on this issue...

This text appears in a few sections:

> 	+ Can partially solve issue #5 if multiple synthetic AAAA records	
> 	  are included in the response and all use same format.

I don't understand this. For the load-balancing use-case I have in mind,
the DNS64 will pick just one of the prefixes and use it for the
synthesis. It will not use all of them for constructing the answer
section. So a client cannot determine whether there is a single prefix
or many just by looking at the DNS answer section.

There is also:

> 	- This method is only able to find one NSP even if a network is	
> 	  utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple	
> 	  synthetic AAAA records in response).

This seems to contradict the previous quotation.

Section 4.4 (on the A64 record) says:

> 	+ Can be used to solve Issue #1 and #5.

Could you please explain how it solves issue #5?

Section 4.6 (on DHCPv6) says:

> 	If DHCPv6 would include multiple NSPs issue #5 could be solved as	
> 	well, but only if nodes as a group would select different NSPs hence	
> 	supporting load-balancing. As this is not clear this item is not yet	
> 	listed under PRO nor CON.

(There is similar text in section 4.7 (on RAs).)

I disagree with this viewpoint. The DNS64 server would still be
responsible for load-balancing because it would be used for the vast
majority of cases. As long as the host is able to recognize all the
prefixes, and picks one prefix when it needs to initiate connections
(e.g. to IPv4 literals), we're fine. It wouldn't be the end of the world
if a host would always pick the same prefix because we're assuming that
the DNS would be used for the vast majority of cases.

Furthermore, the DHCPv6 server could assist by e.g. randomizing the
prefixes it gives out so that even client implementations that always
pick the first prefix would tend to use all prefixes equally
(considering a large client population).

Another viewpoint would be to consider the DHCPv6 server itself as
responsible for load balancing, assigning a single prefix to each client
according to a load-balancing algorithm. Each client would always use
the same prefix, and therefore would not need to know about the other
prefixes.

So I think it would be correct to say that DHCPv6 and RAs do solve issue
#5 satisfactorily.

Section 5 (Conclusion) says:

> Issue #5 is considered to be mostly insignificant as	
> even if individual hosts would use only one NSP at a time, different	
> hosts would be using different NSPs, hence supporting load-balancing	
> targets.

I agree on the load-balancing issue, but I think this is missing the
point. If a host does not know about all prefixes, how can it achieve
issue #1? In other words, how can it recognize synthetic addresses using
prefixes it does not know about? I see solving issue #5 as a
prerequisite to solving #1.

Thanks,
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: <[email-masked]>
Date: Fri, 21 Jan 2011 15:30:53 +0100

Hi Jouni,

It would useful if you provide in the I-D more elaboration why the following points are considered as "issues";

"   Issue #4

      The problem of supporting changing NSP.

   Issue #5

      The problem of supporting multiple NSPs."

Do you have in mind load-balancing scenarios as what is described in Section 6.2 of http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-00?

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de jouni korhonen
Envoyé : vendredi 21 janvier 2011 09:16
À : 'behave' ([email-masked])
Objet : [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt

Folks,

- Jouni

> 	Filename        : draft-korhonen-behave-nat64-learn-analysis-01.txt
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

*********************************
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: "Dan Wing" <[email-masked]>
Date: Fri, 21 Jan 2011 07:56:39 -0800

...
> the DNS would be used for the vast majority of cases.

You're right, for today's networks.  But in the future the hosts will
do their own DNSSEC validation and (thus) their own DNS64 synthesis.  At 
that point in the future, the load balancing is done by the host and
how it learned the prefix(es), and is no longer done by the DNS64.

Of course, that future is years away.

With that in mind, the solutions you suggested in the next two
paragraphs seem good suggestions for a solution document:

> So I think it would be correct to say that DHCPv6 and RAs do solve
> issue #5 satisfactorily.

-d

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Jan 2011 19:33:22 +0000

> do their own DNSSEC validation and (thus) their own DNS64 synthesis.  
> At that point in the future, the load balancing is done by the host and 

I don't think it is years away. I have worked with various implementations of instant messaging, VoIP, or distributed games. They all have dedicated software modules for NAT and firewall traversal. They do ICE, UPNP, and all kinds of other tricks. They will indeed incorporate prefix discovery as soon as NAT64 gets deployed in the network. It will certainly not take "years."

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 21 Jan 2011 12:46:02 -0800

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, January 21, 2011 11:33 AM
> To: Dan Wing; 'Simon Perreault'; 'jouni korhonen'
> Cc: ''behave''
> Subject: RE: [BEHAVE] Learning multiple NAT64 prefixes (Was: I-D
> Action:draft-korhonen-behave-nat64-learn-analysis-01.txt)
> 
> I don't think it is years away. I have worked with various
> implementations of instant messaging, VoIP, or distributed games. They
> all have dedicated software modules for NAT and firewall traversal.
> They do ICE, UPNP, and all kinds of other tricks. They will indeed
> incorporate prefix discovery as soon as NAT64 gets deployed in the
> network. It will certainly not take "years."

What about DNSSEC validation on the host?  It's only after DNS64 and 
DNSSEC validation on the host are both deployed that it becomes
necessary for the host to take on all of the DNS64 functions itself.
Prior to that, DNS64 (and DNSSEC validation) can be done by 
a DNS64 device in the network.

-d

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 22 Jan 2011 20:03:12 -0800

"Firstly, finding out whether a particular address is synthetic and
   therefore learning the presence of a NAT64.  For example, a Dual-
   Stack (DS) host with IPv4 connectivity could use this information to
   bypass NAT64 and use native IPv4 transport for destinations that are
   reachable through IPv4.  We will refer this as 'Issue #1' throughout
   the document."

Do we believe this will be a common case, where there is a dual-stack
network with DNS64 in it?  It is not covered in
draft-ietf-behave-v6v4-framework or
draft-arkko-ipv6-transition-guidelines.  Not to say it won't happen,
but is this design that is likely to happen and needs consideration
here?

Section 3 references SDP and SIP using IP literals, they may also use
FQDNs, so they may not be the best example.  In this sense, they are
just like HTTP or FTP, which may use literals and FQDNs.

I am not sure what issue #5 is.  Can you provide more clarification?
I plan on having many NSPs in my network, but i plan on users only
have a view of one.  AFAIK, NSP = PREF64, and there is a tight
coupling of PREF64 and NAT64 system. So, there  is a tight coupling
between NSP and a NAT64 system.  The load balancing i prefer is based
on the DNS64 having access to multiple NAT64 systems for load
balancing traffic to them via control of the NSP/PREF64 that a client
has access to.  But, there is a requirement that the client alway have
the same NSP/PREF64 so that the users has a "sticky" public IP that
represents the IPv6 client via the NAT64 to the IPv4 internet.  Things
break when the user is represented by multiple public IPv4 address
across TCP sessions (VPNs ....)

I prefer "4.3.  DNS Query for a Well-Known Name" since it can be
deployed today.  A lot of the appeal about DNS64 and NAT64 is that end
systems don't have impacts and the solution can be gracefully put in
place without much fiddling or new standards work.  I believe the
EDNS0 solutions require modifying the end systems and thus spoils some
of the benefits of the NAT64 based solutions.

Another option not captured is the manual PREF64 configuration.  The
NAT46 implementation here uses that today

http://code.google.com/p/n900ipv6/wiki/Nat64D

Generally for this solution of dealing with literals, it is perhaps
beneficial to state some guidance that the application can just
attempt to use the WKP if nothing else works.  I think it is also
reasonable to have guidance that /96 NSP prefixes will be easier to
derive with the heuristic method and therefor network operators should
generally use them as opposed to the other size prefixes.

Cameron

---

From: Simon Perreault <[email-masked]>
Date: Sun, 23 Jan 2011 15:54:09 -0500

> of the benefits of the NAT64 based solutions.

Well, if you want the host to use the learned prefix for anything 
useful, you need to add code on the host. Therefore, all proposed 
solution need to modify the host, and could be considered equivalent on 
this aspect.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: jouni korhonen <[email-masked]>
Date: Sun, 23 Jan 2011 23:26:57 +0200

Hi,

>      The problem of supporting changing NSP.

Right. We should say a bit more here. How about:

      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
      might move to a new network that uses different NSP, thus making
      the previously learned NSP stale.  Also, the NSP used in the
      network may be changed due administrative reasons, thus again
      making previously learned NSP stale.

>      The problem of supporting multiple NSPs."

Right. We should say a bit more here. How about:

      The problem of supporting multiple NSPs.  A network may be
      configured with multiple NSPs for address synthesis.  For example,
      for load-balancing purposes each NAT64 device in the same network
      could be assigned with their own NSP.

> Do you have in mind load-balancing scenarios as what is described in Section 6.2 of http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-00?

Actually no.. our load-balancing reference was generic as it was pointed out in Beijing meeting as a reason for having multiple NSPs.

- JOuni

---

From: jouni korhonen <[email-masked]>
Date: Sun, 23 Jan 2011 23:51:41 +0200

Hi Simon,

> multiple prefixes. Here are some specific comments on this issue...

Thanks for spending time and reading this I-D.

> I don't understand this. For the load-balancing use-case I have in mind,

Based on your description below you did seem to understand it..

> or many just by looking at the DNS answer section.

Right, the model of working what we had in mind was that one does 
typical DNS round-robin style load balancing. There the host would 
receive multiple synthesized AAAAs (with NSPs of different NAT64s) 
and in the three cases where the above wording is used, the "solution" 
works if the synthesized AAAAs have NSPs of the same prefix length. 

If the DNS64 only responses with one synthesized AAAA, then yes, the 
above text could/should be rephrased differently. 

> This seems to contradict the previous quotation.

I Don't think so. The thing that should be clarified here is what support 
for multiple prefixes means. For me it just means the network having 
multiple NAT64s just have multiple NSPs out there. How DNS64 then 
synthesizes AAAAs in replies does not really matter. And the DNS replies 
may contain one or more AAAAs with different NSPs. 

> Could you please explain how it solves issue #5?

DNS round-robin with multiple NSPs? Of course the DNS server that 
gets provisioned with A64s has to know adequate NSPs and the
synthesized addresses. 

> the DNS would be used for the vast majority of cases.

Ok.

> prerequisite to solving #1.

Hmm.. For spotting the presence of NAT64 in a network, the host needs to
learn minimum one NSP or an indication of a NAT64. One does not need full
coverage of NSPs for that. On the other hand, if a (dual-stack) host wants
to be absolutely sure that none of the IPv6 addresses it has learned are
synthesized then the host needs to know all NSPs used in that network.

- JOuni

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 09:00:22 +0100

Hi Jouni,

The proposed text for issues 4 and 5 is fine. Thanks.

I'm wondering whether issues 1, 2 or 3 can be extended to cover the case of a host receiving referral objects. Even if DNS is supported by the receiving host, it can not distinguish between an IPv4-embedded IPv6 address and a "native" IPv6 address.  

Cheers,
Med 

-----Message d'origine-----
De : jouni korhonen [mailto:[email-masked]] 
Envoyé : dimanche 23 janvier 2011 22:27
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : 'behave' ([email-masked])
Objet : Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt

Hi,

- JOuni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Jan 2011 10:58:41 -0800 (PST)

These two issues are covered in our drafts 

draft-sarikaya-behave-mext-nat64-dsmip and draft-sarikaya-behave-mext-nat64-pmip
We will submit revised versions soon.

>       could be  assigned with their own NSP.

Regards,

Behcet