Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

[JORDI PALET MARTINEZ <[e-mail]>]

Thanks again for your detailed responses. I will work in the next few days in a very in-depth review, this has been very helpful.

See below, in-line.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <[e-mail]> en nombre de Andrew Sullivan <[e-mail]>
Fecha: martes, 29 de mayo de 2018, 21:38
Para: <[e-mail]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

    Hi,
    
    On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote:
    
    > I understand your point that NAT64 was meant to be "imperfect", but this is something that is not valid for operators. Operators need to support existing customers with existing devices and apps, that only have IPv4 support, and this is only possible with NAT64 + CLAT.
    > 
    
    Obviously, operators have customers and need to support whatever they
    need to support.  It appears that there are people who are using
    464XLAT with DNS64 where that works for them.  I certainly have no
    trouble with something that wants to outline (for instance) how one
    would make a determination about whether anyone downstream is doing
    their own validation.  What I think is wrong here is a generic claim
    that one or another approach is the only right answer, because the
    CLAT in many cases requires more translation (which means more
    overhead and more work that the operator has to do).

I see your point. The question is the operators want to avoid, at all means, user complains, so if you want to make it "perfect", you may prefer more translations, but not breaking DNSSEC. Anyway, I will try to find a way to suggest that you need to determine in your own case if DNSSEC is going to be a problem for your customers and possible alternatives such ACL for specific customers, etc.
    
    > Also, most of the actual usages of 464XLAT are still using DNS64 (except a few like Orange in Poland if I recall correctly), so the point is to explain that you can also solve the DNSSEC issue, when using CLAT (not using DNS64), etc.
    > 
    
    Well, you can indeed.  I think there is nothing wrong with making this
    point, but the document as it is appears to be suggesting that the
    trade-off is not clear in DNS64.  I think RFC 6147 is crystal clear
    about it, so I don't get why this document (which has a much less
    comprehensive treatment of what fails and why) is an improvement.
    
    > So, the goal of the document is to find what is the "best" possible
    > way to deploy NAT64, which in my opinion, in the real world is by
    > using it combined with CLAT.
     
    I don't observe that the document is called "Jordi's opinion on best
    NAT64 deployment scenarios".  If the WG is supposed to work on this,
    then I think it would be better to outline the various trade-offs and
    allow people to make their own choices, fully informed.

Your review is the first "complete" one. A couple of people provided inputs in specific sections ...

Definitively I'm going to work in a new version carefully observing all your inputs. Thanks again. I wish having so many inputs in every document that we have in v6ops, but unfortunately is not happening.
    
    > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I
    > wanted to do the exercise of looking into all possible cases, just
    > to make sure that somebody using the document see what is possible
    > and what is not, instead of making the exercise by themselves.
    
    I see.  Such a section could be massively improved, then, by calling
    out the scenarios that are known not to work, that are broken on
    purpose, and so on.  At the moment, it reads as though these
    alternatives are all live possibilities, but some of them simply
    aren't, were never intended to be, and are not a real problem anyone
    should have.

Right, I will clasify them in different "sub-sections" to make it very clear. Probably will use some tables to make a summary.
    
    > What I disagree with you is in your comment that anyone who is willing to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually not needed in that case.
    > 
    
    I think what I said is that they're going to _be able_ to, not that
    they would.  I do not claim that DNS64 ought to be deployed by anyone.
    It's just a mechanism that is available if it happens to fit a need,
    and each network operator needs to evaluate that.  I claim that the
    I-D as written doesn't actually help people do such an evaluation, and
    that in fact it leaves out some of the necessary analysis.
    
    > Maybe if you see the point that an operator will not be able to provide services without the CLAT, you have a better understanding on the document now.
    > 
    
    It's simply false that an operator will not be able to provide service
    without the CLAT, but it is true that _some_ operators will find such
    a service inadequate.  I believe that's why 464XLAT was invented, in
    fact.  
    
    > Would you agree that if an operator deploying IPv6-only access want to make sure that the customers using some IPv4-only devices work fine, the only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work?
    > 
    
    No.  But I believe that there are operators for whom that will be
    true.  I also believe there are operators for whom 464XLAT with DNS64
    is a viable and useful option in some scenarios, particularly having
    to do with the costs of double translation.  I'm not opposed to a
    document that attempts to lay out the trade-offs.  I am very much
    opposed to a document that attempts to say there's only one way that
    works, because it isn't true.  Indeed, for some values of "works",
    _none_ of this qualifies, and the only real answer is native ipv6.

I didn't write correctly the best example for you to answer this question. Basically, what I wanted to ask is NAT64+DNS64 vs NAT64+DNS64+CLAT.
    
    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [e-mail]
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.