Re: [sunset4] [v6ops] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt

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

My initial perspective on this, and that’s why I think it can be part of the 7084-transtition document, is that it only makes sense if it can be done by means of a transition mechanism in the CE, so not requiring an existing operator to deploy anything new.

For example, let’s assume an operator has already NAT64, deployed during the transition from an IPv4-only network to an IPv6-only one. They deployed a few NAT64 and DNS64 boxes, together with CEs that were configured for doing 464XLAT.

Now after a few years, they can probably have “less” NAT64 boxes, as there is less and less IPv4 traffic, however, new customers in the network (may be coming from IPv4-only operators), still require some IPv4 service. So, if the operator kept “some” NAT64 boxes, they can still offer “on-demand” IPv4, because the CLAT in the CE is automatically taking care of this.

I’m not actually sure (need to work on that), if there is “anything” new to add to my existing document, or just some text to clarify that this sort outs problems documented in draft-ietf-sunset4-gapanalysis.

Saludos,
Jordi
 

-----Mensaje original-----
De: Fred Baker <[e-mail]>
Responder a: <[e-mail]>
Fecha: jueves, 17 de agosto de 2017, 1:30
Para: JORDI PALET MARTINEZ <[e-mail]>
CC: "[e-mail]" <[e-mail]>, <[e-mail]>
Asunto: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt

    Hatless...
    
    The question I would ask is whether on-demand IPv4 makes sense. To my way of thinking, it amounts to deploying a new kind of network. We are asking people to deploy IPv6 in their IPv4 networks, or to deploy IPv6-only networks. That requires some portion of the money and time they have available for such issues. Deploying an IPv4-on-demand network is another thing competing for those same resources - it doesn't create new resources or reduce the matters pertaining to IPv6 deployment - it creates another demand for the same resources. I don't see the point.
    
    I suspect that the network actually routes IPv4 no matter what; what is being handed out on demand is an IPv4 address to an edge device. Hosts right now get IPv4 (and IPv6) addresses when they don't need them so they can use them when they do. They would need a different mode of operation, perhaps triggered by the resolver noticing that an application wants to access some name and the name only has an A record. In that mode of operation, the host only asks for (DHCP) an IPv4 address when it needs it, and routing in the network is to the granted address for the lifetime of the address.
    
    Do I believe we can describe and solve that? Yes. Do I think we can do it more cheaply and simply than moving folks and their applications to IPv6, and convince operators to change their operational practices accordingly? Not even close. I think it is a diversion from IPv6 deployment.
    
    > On Aug 16, 2017, at 2:08 PM, JORDI PALET MARTINEZ <[e-mail]> wrote:
    > 
    > (copying v6ops)
    > 
    > Forgot something here regarding:
    > 
    > 4. Write a guidance document for IPv4-on-demand, covering problems 10-14.
    > 
    > I think this can be done in draft-palet-v6ops-rfc7084-bis-transition-00, which I plan to review next week (in this case I believe it belongs to v6ops), otherwise, I will draft something else (need to identify then if v6ops, sunset4 or some other WG).
    > 
    > Regards,
    > Jordi
    > 
    > 
    > -----Mensaje original-----
    > De: sunset4 <[e-mail]> en nombre de Lee Howard <[e-mail]>
    > Responder a: <[e-mail]>
    > Fecha: miércoles, 16 de agosto de 2017, 18:27
    > Para: "Liushucheng (Will Liu)" <[e-mail]>, "[e-mail]" <[e-mail]>
    > Asunto: Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt
    > 
    >    I admit, it’s been a long time since I’ve read this draft.
    > 
    >    One capability gap we still have: there’s no IPv6 version of FlowSpec.
    >    There is an idr WG draft, but it hasn’t had a lot of discussion in recent
    >    months: 
    >    https://datatracker.ietf.org/doc/html/draft-ietf-idr-flow-spec-v6-08
    > 
    >    Review of the gap-analysis draft: (summary at the bottom)
    >    There are 16 specific problems identified. Some solutions are proposed in
    >    Annex A; I’d rather see those incorporated into the text.
    > 
    >    Can problems 1-5 (indicating that IPv4 is unavailable, disabling IPv4 in
    >    the LAN) be addressed with recommendations in any, some, or all of:
    >    draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers"
    >    draft-ietf-v6ops-rfc7084-bis-04  “Basic Requirements for IPv6 Customer
    >    Edge Routers"
    > 
    >    Or other drafts under discussion in v6ops now?
    >    Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable (as in
    >    A.1.1 and A.1.2)?
    > 
    >    Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with
    >    draft-ietf-v6ops-rfc6555bis-03,  "Happy Eyeballs Version 2: Better
    >    Connectivity Using Concurrency”?
    > 
    > 
    > 
    >    Problems 8 and 9 are about surprises when IPv4 support is removed from the
    >    kernel. I remember reading about this several years ago; should we have a
    >    hackathon to repeat the experiment?
    > 
    >    I’m not very clear on the IPv4-on-demand scenario described in Section 6
    >    (and I don’t understand the solution in A.4). But we should probably write
    >    a guidance document on how to handle problems 10-14, don’t you think?
    >    Anyone want to volunteer for that?
    >    Could Problem 10 be addressed in Happy Eyeballs v2, rfc6555bis?
    > 
    >    Problem 15 (IPv4 address literals) is mitigated with most transition
    >    technologies, isn’t it? Not NAT64 (requiring DNS64), but 464xlat, DS-Lite,
    >    MAP.
    > 
    >    I like the solutions proposed for Problem 16 (Router IDs): Just pick a
    >    32-bit number and use it as the last 32 bits of the IPv6 address. If you
    >    try, you could use it in multiple prefixes on the same router, including
    >    Loopback, Link Local, and even GUAs. I’m not entirely sure this problem
    >    qualifies as a gap, so much as an operational consideration.
    > 
    > 
    >    Summary of proposed actions:
    >    1. Ask authors of draft-ietf-v6ops-ipv6rtr-reqs-00 and
    >    draft-ietf-v6ops-rfc7084-bis-04  to consider whether they can respond to
    >    problems 1-5.
    >    2. Confirm that problems 6-7 are resolved in rfc6555bis, and ask whether
    >    problem 10 can be.
    >    3. Hackathon removing IPv6 support from the kernel. If it’s an IETF
    >    Hackathon, need a Champion who is comfortable hacking the kernel. Would be
    >    great to include people from Windows, Apple, Android.
    >    4. Write a guidance document for IPv4-on-demand, covering problems 10-14.
    > 
    > 
    >    I will do the first two things.
    >    Do people agree with the other two things? Anyone want to volunteer?
    > 
    >    Lee
    > 
    > 
    > 
    > 
    >    On 8/3/17, 7:08 AM, "sunset4 on behalf of Liushucheng (Will Liu)"
    >    <[e-mail] on behalf of [e-mail]> wrote:
    > 
    >> Hi all,
    >> 
    >> We've updated the draft according to the comments we received online and
    >> offline. Please take a look and let us know your thought.
    >> 
    >> Thanks!
    >> 
    >> Will
    >> 
    >> -----Original Message-----
    >> From: sunset4 [mailto:[e-mail]] On Behalf Of
    >> [e-mail]
    >> Sent: Tuesday, August 01, 2017 7:32 PM
    >> To: [e-mail]
    >> Cc: [e-mail]
    >> Subject: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt
    >> 
    >> 
    >> A New Internet-Draft is available from the on-line Internet-Drafts
    >> directories.
    >> This draft is a work item of the Sunsetting IPv4 WG of the IETF.
    >> 
    >>       Title           : Gap Analysis for IPv4 Sunset
    >>       Authors         : Will(Shucheng) Liu
    >>                         Weiping Xu
    >>                         Cathy Zhou
    >>                         Tina Tsou
    >>                         Simon Perreault
    >>                         Peng Fan
    >>                         Rong Gu
    >>                         Chongfeng Xie
    >>                         Ying Cheng
    >> 	Filename        : draft-ietf-sunset4-gapanalysis-09.txt
    >> 	Pages           : 11
    >> 	Date            : 2017-08-01
    >> 
    >> Abstract:
    >>  Sunsetting IPv4 refers to the process of turning off IPv4
    >>  definitively.  It can be seen as the final phase of the transition to
    >>  IPv6.  This memo enumerates difficulties arising when sunsetting
    >>  IPv4, and identifies the gaps requiring additional work.
    >> 
    >> 
    >> The IETF datatracker status page for this draft is:
    >> https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis/
    >> 
    >> There are also htmlized versions available at:
    >> https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09
    >> https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-gapanalysis-09
    >> 
    >> A diff from the previous version is available at:
    >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sunset4-gapanalysis-09
    >> 
    >> 
    >> 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.
    >> 
    >> Internet-Drafts are also available by anonymous FTP at:
    >> ftp://ftp.ietf.org/internet-drafts/
    >> 
    >> _______________________________________________
    >> sunset4 mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/sunset4
    >> 
    >> _______________________________________________
    >> sunset4 mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/sunset4
    >> 
    > 
    > 
    >    _______________________________________________
    >    sunset4 mailing list
    >    [e-mail]
    >    https://www.ietf.org/mailman/listinfo/sunset4
    > 
    > 
    > 
    > 
    > **********************************************
    > 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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
    > 
    > 
    > 
    > _______________________________________________
    > 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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.