Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 08:42:02 +0200

Hi Alejandro,

Thanks for the inputs/questions.

Some responses below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Alejandro D'Egidio <[email-masked]>
Fecha: martes, 12 de junio de 2018, 22:55
Para: <[email-masked]>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

    Hello,
    First at all, I've read all the thread and I think this is a very useful discussion.
    I work in a cable operator and I think 464XLAT is a great idea to be included in CPEs. So, everything related to that is interesting for me.

-> You're not alone, many people is considering 464XLAT, so welcome to the club.

    I have some questions:
    1- Why the RFC8026 can include Option Codes for many transition methods and not for 464XLAT?

-> I've looked at many option codes for DHCPv6 options, and I've seen that is done without any problem when needed in other IETF documents, so I clearly believe we should do that, so we can have a priority and on/off switch for every protocol. As Barbara said operators should be able to choose if they want the CE to use a mechanism or not.

    2- Why we can't have an alternative to RFC7050 and RFC7225?

-> We proposed some time ago a mechanism based in a new DHCPv6 option but was not accepted. The reason most of the time this doesn't happen is that operators aren't contributing to IETF to tell "yes I need this (or I don't need that)". Is not an issue for the scope of this document, but I agree, it will be good to have it. That document is expired, but still available if you want to take a look (https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01). Note that in any case, this is not being discussed now (and is not a topic for this WG).

    3- What if some CPEs works fine with some RFCs and not with other? Shouldn't be better to have alternatives? It's really common to have many Bugs in CPEs specially with new protocols. They can say they support some RFC but it doesn't work and you will need to wait some months (if you're lucky) to get the solution.

-> Not sure to understand your point here. However, what we are trying, precisely, is to make sure that the CPEs intended for the transition (supporting IPv4 while we need it, on top of IPv6-only networks), follow a single document, the same way we have RFC7084 when no transition at all is needed.

    4- In our cablemodems we doesn't allow to customer to modify DNS configuration but, what about if customer change cablemodem to Bridge Mode and connects it's own CPE? This is a usual case where you can't control DNS configuration but you still want to use 464XLAT.

-> Right, this is one more reason to have the support of 464XLAT without DNS64, and thus an RFC8026 option to prioritize and switch on/off the mechanism.

    Thanks and Regards,
    
    ALEJANDRO D'EGIDIO 
    Jefe de Ingeniería de Backbone 
    F: +54 11 3977 1025  | M: +54 911 5794 1589 
    Lavardén 157. Piso 3. CABA (C1437FBC)
    
    ----- Mensaje original -----
    De: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
    Para: "Philip Homburg" <[email-masked]>, [email-masked]
    Enviados: Martes, 12 de Junio 2018 7:48:07
    Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
    
    I think my earlier email to Lorenzo provides answers to most of this ... but
    
        > I see your point, but
        > what an operator need is a "100% sure" way to make sure that they
        > can tell the CPE to not use a specific transition mechanism (which
        > for the other mechanisms we have with RFC8026).
        > 
        > So, assuming that DNS64 is only there if combined with NAT64 is
        > not "safe 100%" because if using CLAT, you can avoid having a DNS64
        > (this is the one that breaks DNSSEC, in case I wrote it incorrectly
        > before).
        
        I'm saying that if an operator uses DNS64 to signal the presence of NAT64,
        then that is a reliable signal that doesn't need an additional DHCP option.
        
        So if is safe for a CPE to just do RFC7050, because if DNS64 is detected,
        you can be sure that the operator wants the CPE to use NAT64.
    
    As said, you can use the CLAT w/o DNS64, so it is not a safe way to detect the CPE should use or not the NAT64.
        
        > But if the user changed the DNS in the CPE (which is quite common),
        > there will not be DNS64 and still may be the ISP want to have the
        > CLAT running, because is using that for the IPv4 service for that
        > particular customer.
        
        Yeah, what if the user changes settings? Maybe the CPE has a way to force 
        NAT64 on. What do you do then? All bets are off when users start changing
        settings.
    
    An operator wants to make it as proof as possible to user changes. A user has no interest in changing the status of NAT64 (probably they don't know what it means), but they have interested in changing the DNS, because many apps or web sites tell them to change it.
        
        In the context of RFC7050, the CPE can opt to use the original resolvers
        provided by upstream to figure out the translation prefix.
        
        Note that if the CPE uses resolvers configured by the user for RFC7050, then
        is it quite possible that the translation prefix is not discovered (for example
        if the user configures a well known public resolver). Or worse, 
        the user may configure a DNS64 resolver that uses a different prefix.
    
    Right, that's one case, using an alternative DNS64, which will bring alternative NAT64, unless/or the operator is using PCP for the NAT64 provisioning.
        
        > If you agree that the CPE may request a PCP option, etc., then
        > request the S46, I think you are in agreement that we need the S46
        > priority option codes for all the mechanism that we are asking to
        > be supported by the CPE, right?
        
        To the extent that RFC8026 is incomplete, that should be fixed. However as
        Section 2.2 describes, what S46 offers can be done already be done by the
        DHCPv6 server. So S46 just provides a relative priority of different
        mechanisms, not an on/off switch for NAT64.
        
    What it makes this work is the combination of RFC8026 and the CPE behavior. The idea is to have a S46 option to provide a priority in a list of "possible" transition mechanism to a given CPE. If the operator doesn't want that a specific CPE uses NAT64, then the S46 will not contain that option, so the CE will not use it, because will not have a match (even if the CPE is able to use 464XLAT). Not sure if this explanation clarify it ? I'm working on the precise text for that in the ID ...

    **********************************************
    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.

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    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.