Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

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

Hi Jen,

Responding below, in-line.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <[e-mail]> en nombre de Jen Linkova <[e-mail]>
Fecha: miércoles, 17 de octubre de 2018, 11:47
Para: <jordi.palet=[e-mail]>
CC: V6 Ops List <[e-mail]>
Asunto: Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

    On Thu, Oct 11, 2018 at 5:33 AM JORDI PALET MARTINEZ
    <jordi.palet=[e-mail]> wrote:
    > We have worked in an integrated version of two documents:
    >
    > draft-v6ops-byrne-dnssecaaaa
    > draft-palet-sunset4-ipv6-ready-dns-00
    >
    > The new document is now:
    >
    > https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1
    
    The new document starts with:
    "This document defines the timing for implementing a worldwide
       IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
       global IPv6-only deployment."
    
    So you are suggesting that DNS operators have to do some work (in
    quite short timeframe) to facilitate something they might not even
    care about...Not sure it would work.

They should care about providing a good service, right?

A good service today is not just IPv4-only.

    
    Then there is a section 7 (Implementation Timeline) which look a bit
    unrealistic. (I have to confess I wish we had a magic wand to make it
    happen...).
    If I let my imagination run wild...let's say a miracle has happened
    and steps 1-3 are done.
    Obviously *just* adding AAAA RR for A-only names has nothing to do
    with enabling IPv6 for a service.

Clearly, we need to rephrase it. We meant not just the RR part, but of course, having the IPv6 connectivity.


    The service needs to have IPv6 connectivity (which might not even be
    available in the specific location) it needs to be tested etc. Adding

IPv6 free tunnels are available, in case, I doubt, you can't setup a tunnel to your upstream provider or alternatively to any of their upstreams. I've been there, several times, in the most strange and remote locations.

    AAAA w/o doing all of that would just negatively impact user
    experience.
    What would happen if a imaginary website cutekittens.example.net which
    hosts popular videos of kittens (and koals) suddenly gets AAAA RR in
    DNS w/o IPv6 being properly enabled for it? Or even worse, the
    webservice would respond to TCP handshake but would not be able to
    server users over IPv6? Well, I'm sure 99.9% of level1 techsupport
    engineers would tell the unhappy customers "disable IPv6 on your
    device and it would solve your issue". I'm not sure it's want we want.
    
    Also, how exactly are you suggesting to enforce the step 4?
    
    Last but not least: "If there is a failure at the
       deadline in complying with those requirements, the relevant NS, MUST
       be temporarily suspended until there is a subsequent successful
       verification."
    So an NS for cutekittens.example.net got suspended (whatever it means).
    So the server would become unreachable? How could it be fixed/get IPv6 enabled?

We are calling ICANN to take actions and enforce them to the registrars. ICANN has something already in TLD contracts. Is time to enforce it.
    
    "MUST" in RFCs are (usually) for a reason. If you do not follow MUST
    smth bad would happen.
    This draft has a lot of MUST which (IMHO) could not be enforced.

I think trying is much better than just complaining and not doing something. Clearly IETF liaison with ICANN need to take actions here.

Believe it or not, there are still many DNS "operators" that have no idea about IPv6, and a call for action should enforce them to do something.
    
    To sum up, I found draft-v6ops-byrne-dnssecaaaa be more useful and
    realistic. It explains why if you want to use DNSSEC for your zone,
    you should consider enable IPv6.
    
    > -----Mensaje original-----
    > De: <[e-mail]>
    > Fecha: miércoles, 10 de octubre de 2018, 20:30
    > Para: Jordi Palet <[e-mail]>, Jordi Palet Martinez <[e-mail]>, Cameron Byrne <[e-mail]>, Cameron Byrne <[e-mail]>
    > Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    >
    >
    >     A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    >     has been successfully submitted by Jordi Palet Martinez and posted to the
    >     IETF repository.
    >
    >     Name:               draft-bp-v6ops-ipv6-ready-dns-dnssec
    >     Revision:   00
    >     Title:              IPv6-Ready DNS/DNSSSEC Infrastructure
    >     Document date:      2018-10-10
    >     Group:              Individual Submission
    >     Pages:              6
    >     URL:            https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
    >     Status:         https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/
    >     Htmlized:       https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00
    >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec
    >
    >
    >     Abstract:
    >        This document defines the timing for implementing a worldwide
    >        IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
    >        global IPv6-only deployment.
    >
    >        A key issue for this, is the need for a global support of DNSSEC and
    >        DNS64, which in some scenarios do not work well together.  This
    >        document states that any DNSSEC signed resources records should
    >        include a native IPv6 resource record as the most complete and
    >        expedient path to solve any deployment conflict with DNS64 and DNSSEC
    >
    >
    >
    >
    >     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.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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/v6ops
    
    
    
    -- 
    SY, Jen Linkova aka Furry
    
    _______________________________________________
    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.