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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 16 Aug 2017 23:08:20 +0200

(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 <[email-masked]> en nombre de Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 16 de agosto de 2017, 18:27
Para: "Liushucheng (Will Liu)" <[email-masked]>, "[email-masked]" <[email-masked]>
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)"
    <[email-masked] on behalf of [email-masked]> 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:[email-masked]] On Behalf Of
    >[email-masked]
    >Sent: Tuesday, August 01, 2017 7:32 PM
    >To: [email-masked]
    >Cc: [email-masked]
    >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
    >[email-masked]
    >https://www.ietf.org/mailman/listinfo/sunset4
    >
    >_______________________________________________
    >sunset4 mailing list
    >[email-masked]
    >https://www.ietf.org/mailman/listinfo/sunset4
    >

    _______________________________________________
    sunset4 mailing list
    [email-masked]
    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.

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Aug 2017 16:29:02 -0700

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 17 Aug 2017 09:42:52 +0200

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 <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 17 de agosto de 2017, 1:30
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: "[email-masked]" <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt

    Hatless...

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 17 Aug 2017 14:00:37 +0000

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

I think "on-demand IPv4" would be rather easy with PPPoE. Many (telco) ISPs are still using PPPoE, and there's still a lot of equipment and routers that support it. The costliest part of PPPoE was help desk calls for people who forgot their login/password. ISP-managed CE routers (that do PPPoE) have mostly evolved to have this auto-configured by the ISP. But not retail CE routers.

In the early days of the Internet, before the need for persistent IPv4 connectivity --  by applications using keep-alives or autonomously and frequently checking in with some server -- was prevalent, many ISPs that used PPPoE supplied CE routers that timed out the PPPoE connection (usually after about 20 minutes of no WAN-bound IPv4 traffic). They also over-subscribed their IPv4 address space. The delay in establishing the PPPoE connection on-demand (when a WAN-bound IPv4 packet came from the LAN) was small; and in the context of sunsetting IPv4, such a delay would probably be quite acceptable. Chatty applications put an end to IPv4 address over-subscription and PPPoE connections that timed out.

So I think an on-demand solution already exists (complete with aging equipment, code, and operational knowledge). For those who want it.
Of course, no on-demand solution will work as long as there are still a lot of IPv4-only autonomously chatty apps.
Disclaimer: Please don't take this email as a statement that I'm recommending this, or that my employer has any such plans, or that I have emotional attachment to this idea, or that I have some sort of agenda regarding this. I'm providing this purely as technical information, in case people weren't aware of it. 
Barbara

---

From: Lee Howard <[email-masked]>
Date: Thu, 17 Aug 2017 11:41:03 -0400

On 8/17/17, 10:00 AM, "v6ops on behalf of STARK, BARBARA H"
<[email-masked] on behalf of [email-masked]> wrote:

>> The question I would ask is whether on-demand IPv4 makes sense.

>
>I think "on-demand IPv4" would be rather easy with PPPoE. Many (telco)
>ISPs are still using PPPoE, and there's still a lot of equipment and
>routers that support it.

That’s exactly how it reads in the gapanalysis draft: it makes sense for
PPPoE.

However, I will argue to both working groups that we should find an
operator who thinks this is a good idea. I hope we can get them to write
it up. If there is no such operator, we should remove the section (or at
most, footnote it as an idea somebody once thought of).

Lee

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Aug 2017 09:46:17 -0700

> On Aug 17, 2017, at 8:41 AM, Lee Howard <[email-masked]> wrote:
> 
> I will argue to both working groups that we should find an

IIRC, Terastream looked at the idea a few years ago and eventually dropped it. They might be interested to say what their thought processes were - pro and con.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 17 Aug 2017 20:58:54 +0000

> That’s exactly how it reads in the gapanalysis draft: it makes sense for PPPoE.
> 
> However, I will argue to both working groups that we should find an operator
> who thinks this is a good idea. I hope we can get them to write it up. If there
> is no such operator, we should remove the section (or at most, footnote it as
> an idea somebody once thought of).

On-demand IPv4 is unrealistic in today's world. To be useful, it requires a majority of customers have no chatty-to-the-Internet IPv4 apps on their home network. That's many years away, given continuing sales of IPv4-only "Smart" TVs and Blu-ray players. 

As for documenting how to do PPPoE on demand, I consider that unnecessary. It's already known how to do that. The code, equipment, and operational expertise already exists -- especially among ISPs with a history of using PPPoE. BBF even has RG requirements documented for it, and network element and architecture requirements. I see no need to create additional documentation in IETF. IETF has never been a good place to document anything substantive related to PPPoE (PPPoE is not an IETF standard; it was published as an "independent submission" informational RFC because no IETF WG would touch it).

I don't care strongly whether or not on-demand IPv4 is removed from the gapanalysis draft (which I think is what Lee suggested). But I do find it odd that it should be removed just because it would only be useful during the actual sunset of IPv4 (and not in near-term deployments). The analysis does not appear to be written to only discuss near-term problems that might be experienced and potential near-term solutions. This particular section clearly notes that it is only relevant for the time period when IPv4 really is sunsetting. I could certainly envision this might be used many years from now when current dual stack providers start turning down IPv4. It also seems odd to remove the gap analysis just because no-one today wants to deploy it today (which, as the analysis says, would not be a good idea) or document in IETF how to do something that is well-documented elsewhere and wouldn't be useful until years from now. The gap analysis does point to where the solution is currently documented.
Barbara