Re: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)

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

By the way, when you read this:

   As a general conclusion, we should note that, if the network must
   support applications using any of the following:
   o  IPv4 literals
   o  non-IPv6-compliant APIs
   o  IPv4-only hosts or applications

You can't take it out of the context of the document. I think this is where you are getting confused. "if the network", because the context of the complete document, is referring to the user LANs in and operator or enterprise IPv6-only access network, supporting 464XLAT (NAT64 doesn't solve all those problems), but again, in the context of destinations which are IPv4-only or dual-stack, but not "IPv6-only".

We will come to that when we reactivate sunset4 WG, and we decide to recommend that IPv4 is historic, and must be disabled in all the networks ... but that's another history! Meanwhile, if you want a "service" to be reachable by everyone, you need to support some form of dual-stack (for example a DC may be IPv6-only but use SIIT-DC to appear as dual-stack in the public facing interfaces).

Regards,
Jordi
@jordipalet
 
 

El 8/7/19 19:24, "JORDI PALET MARTINEZ" <[e-mail]> escribió:

    Hi Dusan,
    
    I think you're reading it wrong.
    
    This document is about guidelines for deployment of an existing transition mechanism: NAT64 (and a derivate of it, 464XLAT).
    
    NAT64 was designed as a solution for IPv6-only hosts, connected to an IPv6-only access network, to access IPv4-only services (as well as dual-stack ones).
    
    464XLAT also provides a solution for IPv4-only hosts, connected to an IPv6-only access network, to access IPv4-only services (as well as dual-stack ones).
    
    So, the *actual* implementation of 464XLAT/NAT64 doesn't allow IPv4-only hosts to connect to IPv6-only hosts.
    
    *However*, you may be interested in reading this optimization that may solve the problem:
    https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1
    
    Note that this is work-in-progress, and if you wait to the end of the day, you will get a *much better* version of this document. This will solve the problem that you mention if 464XLAT is used.
    
    I will send a notification in the list when I submit the next version, it is taking many more hours than I expected ...
    
    Regards,
    Jordi
    @jordipalet
     
     
    
    El 8/7/19 19:08, "v6ops en nombre de Mudric, Dusan (Dusan)" <[e-mail] en nombre de [e-mail]> escribió:
    
        Section 3.3:
        
        "if the network must
           support applications using any of the following:
        
           o  IPv4-only hosts or applications
        
           Then, only the scenarios with 464XLAT, a CLAT function, or equivalent
           built-in local address synthesis features, will provide a valid
           solution."
        
        Which document explains how 464XLAT and a CLAT function provide connectivity from IPv4only-host to IPv6only-host?
        
        Thanks,
        Dusan.
        
        
        > -----Original Message-----
        > From: v6ops <[e-mail]> On Behalf Of JORDI PALET
        > MARTINEZ
        > Sent: Sunday, July 7, 2019 5:24 PM
        > To: Éric Vyncke <[e-mail]>; The IESG <[e-mail]>
        > Cc: [e-mail]; [e-mail]; v6ops-
        > [e-mail]
        > Subject: Re: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-
        > deployment-06: (with COMMENT)
        > 
        > Hi Eric,
        > 
        > Thanks a lot for your review!
        > 
        > Comments in-line below. Most of them I will reword some text or correct
        > nits, but there are a couple of questions for you to clarify.
        > 
        > Regards,
        > Jordi
        > @jordipalet
        > 
        > 
        > 
        > El 7/7/19 14:59, "v6ops en nombre de Éric Vyncke via Datatracker" <v6ops-
        > [e-mail] en nombre de [e-mail]> escribió:
        > 
        >     Éric Vyncke has entered the following ballot position for
        >     draft-ietf-v6ops-nat64-deployment-06: No Objection
        > 
        >     When responding, please keep the subject line intact and reply to all
        >     email addresses included in the To and CC lines. (Feel free to cut this
        >     introductory paragraph, however.)
        > 
        > 
        >     Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
        > 3A__www.ietf.org_iesg_statement_discuss-
        > 2Dcriteria.html&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJ
        > xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW0t
        > rvZwSDh5SnT8LOzdg&s=LwRXKT1d-8SS5QiUbHNrp33o3TBAeLqgs9RN-
        > UwC0Yg&e=
        >     for more information about IESG DISCUSS and COMMENT positions.
        > 
        > 
        >     The document, along with other ballot positions, can be found here:
        >     https://urldefense.proofpoint.com/v2/url?u=https-
        > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnat64-
        > 2Ddeployment_&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLe
        > aJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW
        > 0trvZwSDh5SnT8LOzdg&s=PHW-
        > a847Dg670Srlft54euH86mfhpwcaNiqzcBPS8v4&e=
        > 
        > 
        > 
        >     ----------------------------------------------------------------------
        >     COMMENT:
        >     ----------------------------------------------------------------------
        > 
        >     Hello Jordi,
        > 
        >     Thank you  for the work put into this clear and well-written document.
        > 
        >     I only wonder whether section 3 and section 4 should be swapped for a
        > more
        >     logical flow: explain the issues, then describe working solutions. Probably
        > too
        >     late in the publication to change though.
        > 
        > I think that will be a major change, because I've a lot of references to the
        > "possible" deployment scenarios to explain the different issues. My "flow"
        > was thinking in how you can deploy it, and then what are the issues that you
        > need to consider.
        > 
        >     The underlying message of "464XLAT solves everything" is annoying but I
        > must
        >     admit that this is true ;-)
        > 
        > This document started as 464XLAT deployment guidelines, and the WG asked
        > me to turn it also to "NAT64". I think that explains it, but in any case, as you
        > well say, it is true ... and there is explicit text to indicate that if you're sure
        > that everything inside the network is supporting IPv6, no literals, etc., then it
        > may be fine with just NAT64. However we all know that this is a non-realistic
        > scenario.
        > 
        >     Please find below many COMMENTs in the hope of improving the
        > readability and
        >     factual data points in the document.
        > 
        >     -éric
        > 
        >     == COMMENTS ==
        > 
        >     Is there a description of the use of DNS64 in the host as it fixes the DNSSEC
        >     issues ? (except in section 3.2.2.)
        > 
        > Not sure to completely understand what you mean here, just trying ... This is
        > not something that the service provider can solve, as it is up to the OS (for all
        > the devices in that network). That's why I think is not something for this
        > document. However, I just realized that this is described in section 7.2 of
        > RFC6147. I can add a reference to that in section 3.2.2.
        > 
        >     -- Section 3.1 --
        > 
        >     "known to work": can you add references or data backing this statement ?
        > 
        > Well, those are the models being used today in cellular and broadband
        > networks. So I can just say that?
        > 
        >     -- Section 3.1.1 --
        > 
        >     When discussing scenarii, please refer to the figure ID in the text for clarity.
        > 
        > Done (I'm already editing a new version while writing this, pending on some
        > that you can provide to my comments).
        > 
        >     -- Section 3.1.2 --
        > 
        >     It is unclear to me whether "The support of this scenario" refers to the
        >     UE-only or the CPE deployment.
        > 
        > It is referring to the "service provider network support". Will clarify it.
        > 
        >     Same demand as above: please refer to the figure ID in the text for clarity.
        > 
        > Done!
        > 
        >     -- Sectio 3.2.1 --
        > 
        >     I really wonder whether it is useful to describe this scenario as 'working
        >     under special conditions'... those 'special conditions' will probably never
        > met
        >     in real life.
        > 
        >     More generally, I am unsure about the value of the whole section 3.2 (it is
        >     more like an academic thing).
        > 
        > I think some of those scenarios are possible in some networks, may be not
        > connecting to Internet, or for example, you may want to configure explicit
        > mappings, which can be done with EAM. I just realized that I've not cited
        > that. I will do.
        > 
        >     -- Section 4.1.1. --
        > 
        >     Can you add reference and/or data for "monitored by some governmental
        > bodies
        >     and other institutions".
        > 
        > I believe that was pointed out by somebody in the WG, but it is true that
        > some regulators do that. I recall having seen something about that in France,
        > but I'm not 100% sure right now.
        > 
        >     Please add a reference for the use of "ipv4only.arpa". AFAIK
        > 
        > Right, this is defined by RFC7050, done!
        > 
        >     draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.
        > 
        > This is one of the issues that I've commented with Warren, responding to
        > IANA. I understand he is sponsoring that document.
        > 
        > 
        >     -- Section 4.1.2 --
        > 
        >     The leading paragraph is a little confusing as it assumed that CLAT exists
        >     (stated in the text but not in the section title).
        > 
        > Will clarify it.
        > 
        >     -- Section 4.1.5 --
        > 
        >     The section title is rather misleading "ACL of clients" and I wonder why a
        >     dual-stack client would use a DNS64 server as its recursive DNS server. Isn't
        >     it an obvious configuration mistake?
        > 
        > No, I think that text is correct, but I will try to reword it to make it clearer. You
        > may have a situation with IPv4-only servers, which are located, in the path
        > between the dual-stack hosts and the NAT64. So, if the DNS64 is not
        > configured to exclude those servers, it will synthetize the AAAA records and
        > they will become unreachable. So that's why bind and other DNS64 servers
        > provide this ACL function.
        > 
        >     -- Section 4.4.1 --
        > 
        >     Some explanations of the consequences of a foreign DNS would be
        > welcome.
        > 
        > Done!
        > 
        >     -- Section 4.4.2 --
        > 
        >     Rather than using "DNS privacy" please use "DNS request confidentiality"
        > as the
        >     DNS64 will learn/glean about the client activities.
        > 
        > I used this terminology as it was suggested as the common one for the
        > different protocols in this category. I will try to confirm if is the right one just
        > in case. May be rewording the title as "DNS Privacy/Encryption Mechanisms"
        > ?
        > 
        > 
        > 
        >     -- Section 4.6 --
        > 
        >     Please explain why older API is a problem (or rather rephrase it into
        >     applications using IPv4-only API).
        > 
        > Done!
        > 
        >     -- Section 4.10 --
        > 
        >     draft-ietf-tram-turnbis is also able to support IPv6-only client. It is
        >     currently in the same IESG status as this document.
        > 
        > Definitively, will add a reference to it!
        > 
        >     -- Section 5 --
        > 
        >     Please add data/references for "with hundreds of millions of users"
        > 
        > I can cite several cellular networks, but I will do in a generic way, I don't think
        > we should mention explicit providers, right?.
        > 
        >     -- Section 7 --
        > 
        >     Not so much about security but about privacy. I would appreciate to have
        > some
        >     text around the lack of privacy when using an external DNS64 as this server
        >     will learn about all clients activities.
        > 
        > Good point, thanks. Will do!
        > 
        >     == NITS ==
        > 
        >     Generally, please refrain from using "HEv2" in place of "Happy Eyeball
        > version
        >     2".
        > 
        > Done!
        > 
        >     -- Section 3.1.1. --
        > 
        >     Figure 1 shows a box containing both NAT64 and DNS64 while those
        > functions
        >     could reside in different devices.
        > 
        > Will clarify it.
        > 
        >     s/One more equivalent scenario/One additional equivalent scenario/ ?
        > 
        > Done!
        > 
        >     -- Section 4.1 --
        > 
        >     s/to an IPv6-only WAN/to an IPv6-only access network/
        > 
        > Done!
        > 
        > 
        >     _______________________________________________
        >     v6ops mailing list
        >     [e-mail]
        >     https://urldefense.proofpoint.com/v2/url?u=https-
        > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
        > l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
        > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
        > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=
        > 
        > 
        > 
        > 
        > **********************************************
        > IPv4 is over
        > Are you ready for the new Internet ?
        > https://urldefense.proofpoint.com/v2/url?u=http-
        > 3A__www.theipv6company.com&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64
        > Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5
        > wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=DJpxsc514-
        > zcfBAFS4ksUO1Az_LzLKo1Da80uIg60JA&e=
        > 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://urldefense.proofpoint.com/v2/url?u=https-
        > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
        > l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
        > ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
        > bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=
        _______________________________________________
        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.