Subject: [sunset4] On-Demand Provisioning of IPv4 Addresses

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Oct 2012 08:52:36 -0400

All,

Cathy Zhou sent me the following addition to the IPv4 sunset gap 
analysis draft. Unless the WG disagrees, I will add it to the -01 
revision (to be published before the IETF85 deadline).

Please also feel free to comment on the technical issue itself.

Thanks,
Simon

> 6.  On-Demand Provisioning of IPv4 Addresses
>
>    As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers
>    will become smaller.  This could be exploited by an ISP to save IPv4
>    addresses by provisioning them on-demand to subscribers and
>    reclaiming them when they are no longer used.  This idea is described
>    in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the
>    context of PPP sessions.  In these scenarios, the home router is
>    responsible for requesting and releasing IPv4 addresses, based on
>    snooping the traffic generated by the hosts in the LAN, which are
>    still dual-stack and unaware that their traffic is being snooped.
>
>    PROBLEM 9:   Dual-stack hosts that implement Happy-Eyeballs [RFC6555]
>                 will generate both IPv4 and IPv6 traffic even if the
>                 algorithm end up chooosing IPv6.  This means that an
>                 IPv4 address will always be requested by the home
>                 router, which defeats the purpose of on-demand
>                 provisioning.
>
>    PROBLEM 10:  Many operating systems periodically perform some kind of
>                 network connectivity check as long as an interface is
>                 up.  Similarly, applications often send keep-alive
>                 traffic continuously.  This permanent "background noise"
>                 will prevent an IPv4 address from being released by the
>                 home router.
>
>    PROBLEM 11:  Hosts in the LAN have no knowledge that IPv4 is
>                 available to them on-demand only.  If they had explicit
>                 knowledge of this fact, they could tune their behaviour
>                 so as to be more conservative in their use of IPv4.
>
>    PROBLEM 12:  This mechanism is only being proposed for PPP even
>                 though it could apply to other provisioning protocols
>                 (e.g., DHCP).

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 25 Oct 2012 15:08:29 +0200

Hi Simon

Nearly missed your email below. Just a few feedback to the problems 9-12 you mentioned in I-D for sunset gap analysis:

Problem 9: RFC6555 recommends a 150-250 ms timeout / head start for IPv6. Assuming that the E2E network connectivity for IPv6 is comparable to IPv4 then no IPv4 connection attempt will be started and no IPv4 traffic will be generated. Hence I-D.fleischhauer can be applied since no IPv4 address has to be provisioned.
Problem 10: What would be an example for such a permanent connectivity check and what percentage of end systems is affected? If this connectivity check is done from an end system in the home LAN to a system in the Internet (and has to use IPv4) then I-D. Fleischhauer can clearly not become effective for this customer. So what :) (I-D.fleischhauer does not assume that it will be effective for 100% of the customers from the beginning.)
Problem 11: ACK. But this would mean massive configurationally adjustments to these hosts.
Problem 12: ACK. But is this (and also Problem 11) really a problem or only a remark?

So far my 2 cents. Kind regards
Olaf 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Simon Perreault
Gesendet: Montag, 15. Oktober 2012 14:53
An: [email-masked]
Betreff: [sunset4] On-Demand Provisioning of IPv4 Addresses

All,

Cathy Zhou sent me the following addition to the IPv4 sunset gap analysis draft. Unless the WG disagrees, I will add it to the -01 revision (to be published before the IETF85 deadline).

Thanks,
Simon

--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sunset4

---

From: Simon Perreault <[email-masked]>
Date: Thu, 25 Oct 2012 11:59:14 -0400

Le 2012-10-25 09:08, [email-masked] a écrit :
> Problem 9: RFC6555 recommends a 150-250 ms timeout / head start for
> IPv6. Assuming that the E2E network connectivity for IPv6 is
> comparable to IPv4 then no IPv4 connection attempt will be started
> and no IPv4 traffic will be generated. Hence I-D.fleischhauer can be
> applied since no IPv4 address has to be provisioned.

Many connections take more than 120-250 ms to establish, even if IPv6 
always ends up winning...

It would be interesting to measure this. My instinct is that just casual 
browsing dual stack sites with happy eyeballs and an IPv6 head start 
would trigger IPv4 traffic within a minute or so.

> Problem 10: What would be an example for such a permanent
> connectivity check and what percentage of end systems is affected? If
> this connectivity check is done from an end system in the home LAN to
> a system in the Internet (and has to use IPv4) then I-D. Fleischhauer
> can clearly not become effective for this customer. So what :)
> (I-D.fleischhauer does not assume that it will be effective for 100%
> of the customers from the beginning.)

I think recent versions of Windows, Mac OS X, Android, iOS all do such 
connectivity checks when a network interface comes up. I think those 
tests include making an HTTP request to a server controlled by the 
vendor (i.e. Microsoft, Apple, Google).

> adjustments to these hosts.

Couldn't the home router tell the hosts using a standard protocol? Maybe 
even one designed by the IETF? ;)

> Problem 12: ACK. But is this (and also Problem 11) really a problem

Let's say that this problem is straightforward to solve. ;) IMHO the 
real question is: is it worth solving?

Simon

---

From: "George, Wes" <[email-masked]>
Date: Thu, 25 Oct 2012 12:53:21 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, October 25, 2012 11:59 AM
> To: [email-masked]
> Subject: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses
> >
> > Problem 10: What would be an example for such a permanent connectivity
> > check and what percentage of end systems is affected? If this
> > connectivity check is done from an end system in the home LAN to a
> > system in the Internet (and has to use IPv4) then I-D. Fleischhauer

[WEG] Windows 7 (and I think vista IIRC) helpfully puts a little warning icon over the network icon in the taskbar to signify that a network connection has "no internet access" but I don't know the specifics of how it is determining this. Implementations of this type should be relatively straightforward to test to see if they complain of "no internet access" when placing them on an IPv6-only but internet-connected network, or slap a sniffer upstream to see what comes out of common OSes when no applications are driving network traffic. If they do complain or send IPv4-only traffic for connectivity checks, that means one of two things- $vendor was not smart enough to use DNS, and hardcoded an IPv4 address in the test or more likely $vendor was not smart enough to dual-stack its chosen test server (yet). I think is a temporary problem, but one worth highlighting in a document like this since it does have the potential to disturb any attempt to do on-demand IPv4 provisioning.
Rather than waving it off as acceptable losses, I'd call it out as a potentially significant gap that defeats this optimization, since it's relatively easily fixed by the vendor.
You could even discuss the alternative of locally spoofing such well-known connectivity checks to intercept them before they force the router to enable IPv4.

Speaking just as an individual,

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Oct 2012 08:27:52 -0700

> -----Original Message-----
> Sent: Thursday, October 25, 2012 8:59 AM
> To: [email-masked]
> > comparable to IPv4 then no IPv4 connection attempt will be started and
> > no IPv4 traffic will be generated. Hence I-D.fleischhauer can be

Yes, for example Windows 7 (and I think Vista and 8) do this
for IPv4, http://blog.superuser.com/2011/05/16/windows-7-network-awareness/

and for IPv6, Windows 8 tries to connect to an IPv6-only server
on the Internet, as described in
http://blogs.msdn.com/b/b8/archive/2012/06/05/connecting-with-ipv6-in-window
s-8.aspx

> real question is: is it worth solving?

I don't see a significant enough advantage to solving the problem,
especially considering the additional user-visible latency when
the user does, in fact, need to use IPv4 (acquiring an IPv4 address
at that time will take several hundred milliseconds).  Also, the
whole purpose of the scheme is to undersubscribe IPv4 addresses (that
is, have fewer IPv4 addresses than necessary), which means there
will be occasions where no IPv4 address is available -- which will
cause customer support calls ("My Internet Is Down").

-d

---

From: <[email-masked]>
Date: Fri, 26 Oct 2012 18:00:16 +0200

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Dan Wing
Gesendet: Freitag, 26. Oktober 2012 17:28
An: 'Simon Perreault'; [email-masked]
Betreff: Re: [sunset4] On-Demand Provisioning of IPv4 Addresses
--------- Snip --------------------------
        Some lines removed
--------- Snip --------------------------
I don't see a significant enough advantage to solving the problem, especially considering the additional user-visible latency when the user does, in fact, need to use IPv4 (acquiring an IPv4 address at that time will take several hundred milliseconds).  Also, the whole purpose of the scheme is to undersubscribe IPv4 addresses (that is, have fewer IPv4 addresses than necessary), which means there will be occasions where no IPv4 address is available -- which will cause customer support calls ("My Internet Is Down").

-d

[Obo]: I can see an advantage for this scheme as the I-D fleischhauer also tries to sketch. 
Regarding the additional user visible latency: Yes you are right, requesting an IPv4 address can take several 100 ms depending on the BRAS system and how you do IPv4 address pool handling, Radius etc. (but we've also observed delays between 100 and 200ms). This will delay the first IPv4 connection attempt (and may at the end result in an incorrect preference of an IPv6 connection for this destination in terms of HE) but when the IPv4 address is provided then the following connection attempts will follow the HE mechanism as usual.
The "My Internet Is Down" syndrome will also happen in today's IPv4 world when the service provider has made a wrong decision regarding the size of its address pools or has done any other misconfiguration and is hence not specific to the approach of I-D fleischhauer. 
Besides right-sizing the IPv4 address pools according to the real needs, I-D fleischhauer also allows to get rid of unused IPv4 addresses in Dual-Stack PPP sessions and could that's why be a needed IPv4 sun setting mechanism.

Just my 2 cents.	
	Olaf

---

From: Rob Shakir <[email-masked]>
Date: Sat, 27 Oct 2012 23:32:59 +0100

> cause customer support calls ("My Internet Is Down").

I think that the problem described in PROBLEM 9 - 12 are valuable to examine. A solution may require tweaks to the solution that is made in the referenced draft and BBF TR-242. One observation is that the problem of the delay in having an IPv4 address allocated might look similar to those in other network environments, such as walk-by mobile users on WiFi (i.e., these users are present, but not necessarily actually sending traffic) but the pool of available addresses at a certain hotspot is limited.

In my view, in a deployment where there is subscriber growth, and a finite set of addresses (which may be less than # of subscribers at some point)  that can be allocated, it would seem to be advantageous to "time share" these addresses, based on the fact that users are not necessarily all active simultaneously, and/or are not accessing IPv4 content simultaneously. As with any statistical multiplexing model, there is a risk that there will be insufficient resources based on a theoretical demand, but accepting this risk is a calculated decision taken by a network operator (akin to that of "do I build my core network to support the theoretical peak of all customers simultaneously?"). I see an advantage in having a mechanism such that an operator can accept this risk, rather than concluding that the advantage of any change is "not significant enough" to examine the problem.

It would seem to me that the advantage is being able to balance the cost of an alternate translation mechanism (e.g., some form of NAT64/tunnelling with shared addressing etc., with the cost of this infrastructure plus the complexity of holding state in an alternate network device) against the cost of potential support calls.

Cheers,
r.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 28 Oct 2012 09:20:40 -0700

> From: Rob Shakir [mailto:[email-masked]]
> Sent: Saturday, October 27, 2012 3:33 PM
> To: Dan Wing
> Cc: 'Simon Perreault'; [email-masked]
> > especially considering the additional user-visible latency when the
> > user does, in fact, need to use IPv4 (acquiring an IPv4 address at
> > that time will take several hundred milliseconds).  Also, the whole
> > purpose of the scheme is to undersubscribe IPv4 addresses (that is,
> > have fewer IPv4 addresses than necessary), which means there will be
> > occasions where no IPv4 address is available -- which will cause
> > customer support calls ("My Internet Is Down").
> 
> I think that the problem described in PROBLEM 9 - 12 are valuable to
> examine. A solution may require tweaks to the solution that is made in
> the referenced draft and BBF TR-242. One observation is that the problem
> of the delay in having an IPv4 address allocated might look similar to
> those in other network environments, such as walk-by mobile users on
> WiFi (i.e., these users are present, but not necessarily actually
> sending traffic) but the pool of available addresses at a certain
> hotspot is limited.
> 
> In my view, in a deployment where there is subscriber growth, and a
> finite set of addresses (which may be less than # of subscribers at some
> point)  that can be allocated, it would seem to be advantageous to "time
> share" these addresses, based on the fact that users are not necessarily
> all active simultaneously, and/or are not accessing IPv4 content
> simultaneously. As with any statistical multiplexing model, there is a
> risk that there will be insufficient resources based on a theoretical
> demand, but accepting this risk is a calculated decision taken by a
> network operator (akin to that of "do I build my core network to support
> the theoretical peak of all customers simultaneously?").

They're not the same.  Under-provisioning network bandwidth causes 
slowness for everyone, but everyone still gets (some) service.  But
under-provisioning IP addresses causes no service for some users.

> I see an
> advantage in having a mechanism such that an operator can accept this
> risk, rather than concluding that the advantage of any change is "not
> significant enough" to examine the problem.
> 
> It would seem to me that the advantage is being able to balance the cost
> of an alternate translation mechanism (e.g., some form of
> NAT64/tunnelling with shared addressing etc., with the cost of this
> infrastructure plus the complexity of holding state in an alternate
> network device) against the cost of potential support calls.

I would like to understand how MAP in Softwire does not meet that
need.  

And perhaps MAP could provide the desired on-demand functionality 
by mapping all 65535 ports of an IPv4 address on demand.

-d

---

From: Rob Shakir <[email-masked]>
Date: Mon, 29 Oct 2012 18:55:46 +0000

Hi Dan,

> by mapping all 65535 ports of an IPv4 address on demand.

I don't think that PROBLEM 9 - 11 are solely related to an IPv4-on-demand solution as is described in the preceding paragraph in the draft. Essentially, equally these problems could be applied to the question of how one ensures MAP usage is minimised c.f. native IPv6. 

In parallel, I do not think that we should immediately dismiss an IPv4-on-demand solution such as the one proposed in draft-fleischhauer-ipv4-addr-saving based on the fact that it re-uses a large amount of existing operational concepts/understanding and existing BRAS deployments. The deployment of MAP or other mechanisms requires new operational concepts around multiple users being present on a single IPv4 address, and deployment and understanding of MAP BR functions.   

Cheers,
r.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Oct 2012 12:01:19 -0700

> Sent: Monday, October 29, 2012 11:56 AM
> To: Dan Wing
> >> It would seem to me that the advantage is being able to balance the
> >> cost of an alternate translation mechanism (e.g., some form of
> > And perhaps MAP could provide the desired on-demand functionality by
> > mapping all 65535 ports of an IPv4 address on demand.
> 
> I don't think that PROBLEM 9 - 11 are solely related to an IPv4-on-
> demand solution as is described in the preceding paragraph in the draft.
> Essentially, equally these problems could be applied to the question of
> how one ensures MAP usage is minimised c.f. native IPv6.
> 
> In parallel, I do not think that we should immediately dismiss an IPv4-
> on-demand solution such as the one proposed in draft-fleischhauer-ipv4-
> addr-saving based on the fact that it re-uses a large amount of existing
> operational concepts/understanding and existing BRAS deployments. The
> deployment of MAP or other mechanisms requires new operational concepts
> around multiple users being present on a single IPv4 address, and
> deployment and understanding of MAP BR functions.

I suggested we investigate MAP using all 65535 ports; there is no
address sharing there.

-d

> r.=

---

From: "George, Wes" <[email-masked]>
Date: Wed, 31 Oct 2012 09:14:24 -0400

> Behalf Of Rob Shakir
[WEG] These are both valid concerns, but I do not believe those concerns translate to "don't look at this problem". Rather, I think these are things that need to be well-discussed, along with potential solutions to mitigate or reduce the impact of these issues. For example, we do a disservice if we don't note that any address-sharing as a means to conserve addresses only works in limited circumstances, and absolutely requires a strong focus on moving as many things away from using IPv4 as possible to reduce the load, or possibly a carefully chosen subset of customers to apply it to. Discussing that potential IPv4 address assignment on-demand delay is another part of articulating the future world where IPv4 access is likely to be impaired in any number of ways with varying degrees of unpleasantness. IMO, any ISP that believes that they aren't likely to see increased support calls using any IPv4 address extension technology, especially if they aren't combining it with aggressive IPv6 deployment and push for content transition is in denial. We're better off noting it up front.

> sending traffic) but the pool of available addresses at a certain
[WEG] +1 - Much as with the rest of sunset4, this is about rethinking what IPv4 access means going forward. Back when dinosaurs roamed the internet and everyone used modems, IPv4 access was on-demand, and programs were even built to manage that (eg a setting that says "don't request network access unless you detect an active PPP connection" to keep a program from firing up the modem unattended). Same drill happened in wireless world, where turning off the network access during periods of idle was both a battery conservation/RF capacity conservation and address conservation mechanism. My previous employer didn't use NAT on wireless for years because it was able to pool addresses at a reasonable oversub rate. The change brought on by always-on wireline IPv4 connectivity bled over into wireless with smartphones, and that stopped working, but I think there's an argument to be made that part of shutting down IPv4 is being cognizant of the fact that it may not be "always-on" and building your apps and infrastructure based on that updated assumption. Indeed that may be necessary even if the primary goal isn't IPv4 address conservation as an intermediate step to turning IPv4 off completely.

> the theoretical peak of all customers simultaneously?"). I see an
[WEG] Again, +1. The statistical analysis you have to do here to determine your oversub rate really has to do with IPv6 uptake in your particular network application - the more IPv6 you deploy and your users can use (because their chosen content and devices are IPv6-capable) the more IPv4 oversub you could do without causing significant breakage. There's a happy medium to be found. Other alternatives to extend IPv4 addresses (NAT, etc) require equipment deployment, which isn't cheap, and in some cases is only likely to be useful for a single digit number of years, potentially for less time than a standard depreciation cycle. So it may be attractive in some cases to have alternatives that don't require that equipment deployment but are still mindful of the continued need for IPv4 service.

The previous comments were made as an individual, not as a chair.

Wes George