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

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

It may depend on "where" is located the proxy.

I don't think this is something that is used. If you have a dual-stack service or website, I don't see why it is practical to have it in different hosts. I see the same host having different apache "virtual servers" if you really want to show different contents for IPv4 and IPv6, but even do ... I really doubt.

If an IPv6-only DC is using SIIT-DC, I also don't see the case where this will fail. I will investigate a bit more, just in case.

Regards,
Jordi
 
 

El 29/3/19 9:18, "v6ops en nombre de Martin Huněk" <[e-mail] en nombre de [e-mail]> escribió:

    I'm not sure about that. In case of NAT64 it would reach the destination by 
    IPv4, then trough a proxy to IPv6 only host. Same goes for 464XLAT. Not 
    mentioning that in such case it should go directly over IPv6.
    
    Maybe I'm just imagine things, I'm not in content delivery, but I think that 
    this situation might happen in IPv6-only datacenter.
    
    Martin
    
    Dne pátek 29. března 2019 9:09:44 CET, JORDI PALET MARTINEZ napsal(a):
    > Unless I'm wrong, this will also fail with the standard NAT64/DNS64 behavior
    > !
    > 
    > So, we aren't breaking anything at it is broken already :-(
    > 
    > Regards,
    > Jordi
    > 
    > 
    > 
    > El 29/3/19 9:06, "v6ops en nombre de Martin Huněk" <[e-mail]
    > en nombre de [e-mail]> escribió:
    > 
    >     Let say:
    > 
    >     # Here is HTTP proxy
    >     www.example.com   IN A 192.0.2.64
    >     www.example.net   IN A 192.0.2.64
    > 
    >     # Here are IPv6-only hosts
    >     www.example.com   IN AAAA 2001:db8::1:1
    >     www.example.net   IN AAAA 2001:db8::2:1
    > 
    >     Now if one (or multiple) host asks for both sides what would be in EAMT?
    > 
    >     Martin
    > 
    >     Dne pátek 29. března 2019 8:56:17 CET, JORDI PALET MARTINEZ napsal(a):
    >     > Hi Martin,
    >     > 
    >     > Not sure to completely understand you. May be an explicit example will
    >     > make
    >     > it more obvious to me, but see first the following:
    >     > 
    >     > The EAMT will create an entry with an AAAA (if available) for each A.
    >     > 
    >     > So, if it works with "DNS" it will work with the EAMT.
    >     > 
    >     > Regards,
    >     > Jordi
    >     > 
    >     > 
    >     > 
    >     > El 29/3/19 8:52, "v6ops en nombre de Martin Huněk"
    >     > <[e-mail]
    >     > 
    >     > en nombre de [e-mail]> escribió:
    >     >     Hi Jordi,
    >     >     
    >     >     I would like to point out a question I've asked to you after
    >     >     session:
    >     >     
    >     >     Would it work if a multiple sides would be under the single proxy
    >     >     on
    >     > 
    >     > IPv4, but on separate hosts on IPv6? Wouldn't it make just one side
    >     > accessible and rest would be pointed to wrong server?
    >     > 
    >     >     Regards,
    >     >     Martin
    >     >     
    >     >     Dne čtvrtek 28. března 2019 16:49:24 CET, JORDI PALET MARTINEZ
    > 
    >     napsal(a):
    >     >     > Hi Dave,
    >     >     > 
    >     >     > After the meeting, I figured out that that's probably easier and
    >     >     > no
    >     >     > need to
    >     >     > determine if it is an IPv4-only host.
    >     >     > 
    >     >     > We can just create the EAMT entry for any A request if there is
    >     >     > a
    >     >     > corresponding AAAA which doesn't contain the WKP or NSP. This
    >     >     > means
    >     >     > that
    >     >     > the end-host (CDN) is dual-stacked.
    >     >     > 
    >     >     > Then any host using the A record will automatically get the
    >     >     > NAT46
    >     >     > translated to the "real" AAAA, not the one with the WKP or NSP,
    >     >     > so we
    >     >     > fulfil the intended optimization not requiring knowing if the
    >     >     > host is
    >     >     > IPv4-only.
    >     >     > 
    >     >     > I think that's what you are meaning?
    >     >     > 
    >     >     > The other think is how to select what AAAA to use if there are
    >     >     > several.
    >     >     > 
    >     >     > I really think it will be interesting to get some co-authors, or
    >     >     > at
    >     >     > least
    >     >     > good inputs from CDN/caches operators on this.
    >     >     > 
    >     >     > Regards,
    >     >     > Jordi
    >     >     > 
    >     >     > El 28/3/19 15:35, "Dave Plonka" <[e-mail]> escribió:
    >     >     >     Hi Jordi -
    >     >     >     
    >     >     >     Thanks for this draft presentation in v6ops.
    >     >     >     
    >     >     >     As we mentioned in the v6ops meeting, I don't think a CPE
    >     >     >     (or any
    >     >     >     remote host) can reliably determine if a given IPv4 DNS
    >     >     >     client is
    >     >     >     an
    >     >     >     IPv4-only host.
    >     >     >     
    >     >     >     For one, this is because dual-stack hosts have at least two
    >     >     >     different
    >     >     >     IP addresses (v4 and v6), as you know, and there isn't a
    >     >     >     simple
    >     >     >     way to
    >     >     >     remotely determine that a given IPv4 address and a given
    >     >     >     IPv6
    >     >     >     address
    >     >     >     are actually bound to the same host's interface(s), or even
    >     >     >     to
    >     >     >     enforce
    >     >     >     that a dual-stack host will query the same DNS recursive
    >     >     >     service
    >     >     >     when
    >     >     >     using two (or more) different client (IPv4 and IPv6)
    >     >     >     addresses.
    >     >     >     
    >     >     >     However, for your draft, couldn't we just eliminate any
    >     >     >     attempt to
    >     >     >     determine if any hosts are v4-only or not, and always
    >     >     >     synthesize
    >     >     >     the
    >     >     >     IPv4 DNS answers?
    >     >     >     
    >     >     >     I'm not saying I'm in favor of the mechanism overall, just
    >     >     >     saying
    >     >     >     we
    >     >     >     could avoid the unnecessary and error-prone step of trying
    >     >     >     to
    >     >     >     determine if a host is v4 only.
    >     >     >     
    >     >     >     Does that make sense?
    >     >     >     
    >     >     >     Thanks,
    >     >     >     Dave
    >     >     >     
    >     >     >     
    >     >     >     On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
    >     >     >     
    >     >     >     <jordi.palet=[e-mail]> wrote:
    >     >     >     > Hi all,
    >     >     >     > 
    >     >     >     > We have published a new version of this document, taking
    >     >     >     > in
    >     >     >     > consideration a few inputs, clarified some examples, nits,
    >     >     >     > etc.
    >     >     >     > 
    >     >     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat
    >     >     >     > -opt-c
    >     >     >     > dn-cac
    >     >     >     > hes/?include_text=1
    >     >     >     > 
    >     >     >     > Regards,
    >     >     >     > Jordi
    >     >     >     > 
    >     >     >     > El 25/3/19 15:05, "[e-mail]" <internet-
    >     >     
    >     >     [e-mail]> escribió:
    >     >     >     >     A new version of I-D,
    >     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    >     >     >     >     has been successfully submitted by Jordi Palet
    >     >     >     >     Martinez and
    >     >     >     >     posted
    >     >     >     >     to the
    >     >     >     >     IETF repository.
    >     >     >     >     
    >     >     >     >     Name:              
    >     >     >     >     draft-palet-v6ops-464xlat-opt-cdn-caches
    >     >     >     >     Revision:   01
    >     >     >     >     Title:              464XLAT Optimization for
    >     >     >     >     CDNs/Caches
    >     >     >     >     Document date:      2019-03-25
    >     >     >     >     Group:              Individual Submission
    >     >     >     >     Pages:              10
    >     >     >     >     URL:
    >     >     >     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops
    >     >     >     >     -464xl
    >     >     >     >     at-op
    >     >     >     >     t-cdn-caches-01.txt Status:
    >     >     >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464
    >     >     >     >     xlat-o
    >     >     >     >     pt-cd
    >     >     >     >     n-caches/ Htmlized:
    >     >     >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat->     >     >     >     opt-cd
    >     >     >     >     n-cac
    >     >     >     >     hes-01 Htmlized:
    >     >     >     >     https://datatracker.ietf.org/doc/html/draft-palet-v6op
    >     >     >     >     s-464x
    >     >     >     >     lat-o
    >     >     >     >     pt-cdn-caches Diff:
    >     >     >     >     https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-46
    >     >     >     >     4xlat->     >     >     opt-c dn-caches-01    >
    >     >     >     >     
    >     >     >     >     Abstract:
    >     >     >     >        This document describes the drawbacks of IP/ICMP
    >     >     >     >        Translation
    >     >     >     >        Algorithm (SIIT), when used as a NAT46, and
    >     >     >     >        IPv4-only
    >     >     >     >        devices
    >     >     >     >        or
    >     >     >     >        applications initiate traffic flows to dual-stack
    >     >     >     >        CDNs
    >     >     >     >        (Content
    >     >     >     >        Delivery Networks) or Caches, which are forced to
    >     >     >     >        be
    >     >     >     >        translated
    >     >     >     >        back
    >     >     >     >        to IPv4 by a NAT64.  The document proposes possible
    >     >     >     >        solutions
    >     >     >     >        to
    >     >     >     >        avoid that.
    >     >     >     >     
    >     >     >     >     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
    >     >     >     
    >     >     >     --
    >     >     >     
    >     >     >     [e-mail]  http://www.cs.wisc.edu/~plonka/
    >     >     > 
    >     >     > **********************************************
    >     >     > 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.
    > 
    > 
    > 
    > _______________________________________________
    > 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.