Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt

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

Hi Martin,

I use Outlook and it doesn't allow (as I know) anything else than indentation. I will try to find a solution, I just need some time ... but is not top priority.

When I see my emails back in the list, it works for me, so it is dificult ...

See below, in-line.

Regards,
Jordi
@jordipalet
 
 

El 24/6/19 23:14, "v6ops en nombre de Martin Hunek" <[e-mail] en nombre de [e-mail]> escribió:

    Hi Jordi,
    
    See below in-line.
    
    Regards,
    Martin
    
    Post Scriptum: My e-mail client doesn't seems to like indentation as quotation mark. Could you change your client settings to use '> '? It is hard to distinguish who wrote what.
    With your client is should be in:
    Options -> Mail -> "When replying to a message" -> "Prefix each line of the original message"
    
    Dne pondělí 24. června 2019 1:09:14 CEST, JORDI PALET MARTINEZ napsal(a):
    > Hi Martin,
    > 
    > Thanks for reading the document!
    > 
    > See below in-line.
    > 
    > Regards,
    > Jordi
    > @jordipalet
    >  
    >  
    > 
    > El 24/6/19 0:28, "v6ops en nombre de Martin Hunek" <[e-mail] en nombre de [e-mail]> escribió:
    > 
    >     Hi Jordi, hi all,
    >     
    >     Same question I asked you at IETF 104:
    >     
    >     How did you solve situation in which multiple IPv6 services would share single IPv4 to IPv6 proxy?
    > 
    > When you mean a proxy, what do you exactly mean? I'm confused here with your example. Do you refer to SNI ? If that's the case, I believe it is resolved already, because what it matters here is the IPv6 address (the AAAA).
    
    Sort of. I mean essentially IPv4 web proxy shared by multiple IPv6 only servers. Proxy would use SNI to distinguish between target server to which it would send payload to. Thing is that you won't be able to do concurrent bindings in EAMT table for this case.

-> We need to see if this is really common. My guess is that even if you use SNI, the IPv4 and the IPv6 page is still hosted by the same dual-stack server. In that case, I don't think we have the problem you mention. You are describing a case where the IPv4 and IPv6 content is hosted by a different server, not a dual-stack one, right? We really need to check if CDNs/caches do that.

    > 
    > If I'm using and IPv4 browser and query to a.example.com, I will go to the same IPv4 address that if I query for b.example.com.
    
    So far so good.
    > 
    > Remember that what it matters here is the contents in IPv6, because the EAMT entry will bring the SmartTV (for example) either to the AAAA for a.example.com or b.example.com. So, if those AAAA provide the right address for IPv6, for the right service, it should work correctly.
    
    No problem on IPv6 side, problem would be to which IPv6 destination should IPv4 destination get mapped to. As in that case you get two bindings in EAMT:
    192.0.2.1 <-> 2001:db8::a
    192.0.2.1 <-> 2001:db8::b
    Both would be valid but which should be chosen by NAT46?
    > 
    > Otherwise (according to your example), you get different results for an IPv4 only host and IPv6-only hosts. Normally this is not done in production services, and again, if this is done, the result of the optimization is like the IPv4-only SmartTV is actually an IPv6-enabled one, so it works again, as intended.
    
    Maybe it is bit "ad absurdum" case, certainly for CDNs. But I think that it is not discouraged/prohibited and I can see its use for VPS provider which would like to save some IPv4 addresses. By the way, it would be somehow similar to what you are proposing: get IPv6-only services accessible by IPv4-only hosts. Only tools would be different.

-> We need to see if this is a real and usual production case. IPv6-only services today can be deployed with SIIT-DC to allow dual-stack access, but this will not suffer the problem you mention.

    >     
    >     Example:
    >     a.example.com		IN A		192.0.2.1		<- This is a proxy
    >     					IN AAAA	2001:db8::a		<- This is a real server
    >     b.example.com		IN A		192.0.2.1
    >     					IN AAAA	2001:db8::b
    >     
    >     Now if you would have for example 2 IPv4-only hosts. One device would communicate with a.example.com, subsequently the second one with b.example.com.
    >     
    >     To which service would second device connect to? What about first device, wouldn't its connection be severed by second device asking for b.example.com?
    >     
    >     If this is not solved by draft (and I cannot see it), I think that this could lead to inaccessible services and non-predictable behavior in general.
    >     
    > We should understand if caches/CDNs are using the scheme that you mention or it is more like (as I guess):
    > 
    >     a.example.com		IN A		192.0.2.1		<- This is a proxy
    >     					IN AAAA	2001:db8::a		<- This is a real server
    >     b.example.com		IN A		192.0.2.1
    >     					IN AAAA	2001:db8::a
    
    No dispute here. CDNs would probably use it this way. But as not all services are provided by CDNs, so their optimization techniques must not brake other services (even less common).
    > 
    > This means (and I think is the *normal* way) to do that, that the "server" is dual-stack and is the "apache" (or whatever), using the SNI the way that resolves the problem. Is that what you mean?
    
    No. I case I'm trying to present multiple servers would be IPv6-only. And A record would point to web proxy (dual-staked) which would proxy web requests according to SNI (or request in HTTP) to appropriate IPv6-only server. Hosting provider would save IPv4 addresses and IPv6-only web server would still be accessible by IPv4. Clearly win-win, except that it would be broken by this optimization.

-> Avoiding the EAMT entry will resolve the problem, but will not be optimized.
    
    Just so we would be on same page, connections to such deployment would look like this:
    a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> Proxy <--- IPv6 ---> IPv6 Server
    b) IPv6 Client <--- IPv6 ---> IPv6 Server
    
    You are proposing:
    c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server
    We can probably all agree that "b" is best and "c" is better than "a". Problem is that you have no way of knowing if you are talking to actual server or just proxy.
    
    Another example when this optimization would not work exactly as planted would be case in which service provider deployed IPv6 by NAT64 placed before its IPv4-only infrastructure. But in this case I would say that such operator would deserve higher load on its NAT64. :-)
    This would be case:
    d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server
    Optimization would result in:
    e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server
    But in this case NAT64 would be in the servers' network rather than clients'. This is actually good as it is transferring load from network doing IPv6 right to network doing it wrong. :-)

-> I think d) is using "only" NAT64, but it is a broken model, because it doesn't work for IPv4-only hosts behind the CPE. So not in scope for our document. e) is the "normal" case for 464XLAT when we don't have the optimization described in this document.

    > 
    >     Possible solution:
    >     Maybe this could be solved by some kind of "blacklist for shared IPv4 addresses with different IPv6 target" thing. This situation should be detectable if there would be EAMT record already present with different IPv6 address. Then if CPE would ask for DNS record which created EAMT record and DNS record has not changed it should delete EAMT and blacklist that IPv4 address so it would not make more EAMT records for it.
    > 
    > Right now, we have this in the ID:
    > TBD.  Should a way to manually exclude EAMT entries be considered?
    >    May be a manual config in the CPE and by means of operator config.
    >    This is way-out to ensure nothing is broken by surprise and is not
    >    solvable.
    > 
    > May be what you mention help to be able to also do it automated.
    
    Doing it manually would not quite cut it as you are proposing to done optimization on CPE and as it may be under customer control, you may not be able to provision it with updated EAMT excludes. It had to be somehow automated as it would be hard to instruct customer to modify EAMT by hand.

-> Agree that manually only makes sense if there is a strange case or the user for some reason doesn't want optimization. It is a special case 99% of users will not use it, but must be supported.
    
    However there is also trade-off with automated approach as it would have to either severe session for user which is already using present binding (when conflicting binding appears). As user starts to communicate over IPv4 (from servers' perspective) as it would get excluded from EAMT. Or you would have to forge fake IPv4 for conflicting binding and corresponding A record, which would break DNSSEC.

-> I can't parse the complete paragraph ...

    
    The first case wouldn't be big deal but might be worth mentioning, the second one would be in my opinion worse.
    >     
    >     Apart of this, it seems like good idea, but I think that it should really be solved as we may see such things with shortage of IPv4 addresses.
    >     
    >     Regards,
    >     Martin
    >     
    >     Dne pátek 21. června 2019 1:40:59 CEST, JORDI PALET MARTINEZ napsal(a):
    >     > Hi all,
    >     > 
    >     > We just published a new version of this document, which we believe has resolved all the issues and inputs received in the last meeting in Prague, and some new additional considerations.
    >     > 
    >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
    >     > 
    >     > Please provide your inputs!
    >     > 
    >     > Regards,
    >     > Jordi
    >     > @jordipalet
    >     >  
    >     >  
    >     > 
    >     > El 21/6/19 2:38, "[e-mail]" <[e-mail]> escribió:
    >     > 
    >     >     
    >     >     A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt
    >     >     has been successfully submitted by Jordi Palet Martinez and posted to the
    >     >     IETF repository.
    >     >     
    >     >     Name:		draft-palet-v6ops-464xlat-opt-cdn-caches
    >     >     Revision:	02
    >     >     Title:		464XLAT Optimization
    >     >     Document date:	2019-06-20
    >     >     Group:		Individual Submission
    >     >     Pages:		14
    >     >     URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt
    >     >     Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
    >     >     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-02
    >     >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-opt-cdn-caches
    >     >     Diff:           https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-464xlat-opt-cdn-caches-02
    >     >     
    >     >     Abstract:
    >     >        This document proposes possible solutions to avoid certain drawbacks
    >     >        of IP/ICMP Translation Algorithm (SIIT) when the destinations are
    >     >        available with IPv6.  When SIIT is used as a NAT46 and IPv4-only
    >     >        devices or applications initiate traffic flows to dual-stack CDNs
    >     >        (Content Delivery Networks), Caches or other network resources (in
    >     >        the operator network or Internet), those flows will be translated
    >     >        back to IPv4 by a NAT64.  This is the case for 464XLAT and MAP-T.
    >     >     
    >     >                                                                                       
    >     >     
    >     >     
    >     >     Please note that it may take a couple of minutes from the time of submission
    >     >     until the htmlized version and diff are available at tools.ietf.org.
    >     >     
    >     >     The IETF Secretariat
    >     >     
    >     >     
    >     > 
    >     > 
    >     > 
    >     > **********************************************
    >     > IPv4 is over
    >     > Are you ready for the new Internet ?
    >     > http://www.theipv6company.com
    >     > 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.
    >     > 
    >     > 
    >     > 
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > [e-mail]
    >     > https://www.ietf.org/mailman/listinfo/v6ops
    >     > 
    >     
    >     _______________________________________________
    >     v6ops mailing list
    >     [e-mail]
    >     https://www.ietf.org/mailman/listinfo/v6ops
    >     
    > 
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > 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.
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    > 
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.