ipv4/25s and above

Mailman List Mirror (Read Only)
41

Eric,

I appreciate your willingness to actual consider this rationally.

Every facet of this debate has been fully aired on this forum (and others), numerous times.

Allow me to pick it apart again. Apologies to those who are ad nausem.

Eric Kuhnke wrote:

Option A) Spend engineering time and equipment purchases to implement 240/4 as unicast globally. At present consumption rates and based on the number of entities in ARIN, RIPE, APNIC regions that could *immediately* take /18 to /16 sized blocks of it, please quantify exactly how many years this amount of "new" IP space you predict to be useful before once again reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy of building a sand castle while the tide is coming in.

Option B) Spend engineering time and equipment purchases (yes, very possibly much more time and more costly) to implement ipv6.

This is know a false dichotomy. There is no actual reason to believe that any effort on option A detracts from available effort of option B. And when you purchase your new gear, or update the software, with its many many lines of code changes, it is not unreasonable to expect that at least some might be IPv4 related and that the removal of restriction on 240/4 would be the more trivial of those.

Indeed that is exactly what has been happening since the initial proposals regarding 240/4. To the extent that it is now largely supported or available across a wide variety of gear, much of it not even modern in any way.

Further, presentment of options in this fashion presumes that we have some ability to control or decide how engineering efforts across the entirety of the internet should be spent.

Respectively, amusing and alarming.

To be clear, the only thing preventing the Internet in freely organizing its own efforts is the unwillingness of curmudgeons to remove the reserved status in this particular instance.

As no-one is requesting that you (or others of this persuasion) lend their personal efforts, your concern on the budgeting of efforts is out of place and worse, of dictatorial bend.

For the sake of argument, ignoring above, presuming our control over the internet engineering efforts et al.

Were I to propose to you that 240/4 be utilized only for new or existing organizations with less than /20 total resources or some other useful constraint, it would be easy to see that 240/4 would last a very long time and potentially have quite a significant impact.

Earlier in this thread I contrasted a reduction from 12 to 1 of ip address consumption per new customer, depending on the practices employed by the service provider. As you can see, consumption rate is actually quite flexible, even now, today.

So the answer to your question is it depends how freely it is handed out. Certainly not very long if it is business as usual prior to runout. Potentially much longer if not.

And in a nod to your concern over effort expenditure, but even more so, conscious of 240/4 being the 32bit space last big easy gasp, I would be a strong proponent that it NOT be.

However, even if it were, what exactly are we saving it for, if not for use by those who need it?

Or is it to be a hedge over some eventuality where IPv6 has failed to the point of abandonment? I might actually respect that position, even as I doubt (and fear and hope against) such an eventualities actual occurrence.

The more galling aspect of the 240/4 wars is that "it will take too long and then Ipv6 will be deployed" crowd that managed to stifle it initially continue to reuse that line again, in essence blase self perpetuation.

Its only taking that long because of this attitude.

Joe

42

In a theoretical scenario where somebody was global benevolent dictator of ipv4 space, even applying a policy which limited block size to a few /14 per ISP, it would be possible to exhaust 240/4 in one week if they handed out /14 sized pieces to every existing last mile LTE network operator with 5+ million customers globally. It is not a long term solution or even a good medium term solution.

43

David Conrad wrote:

Barry,

We've been trying to get people to adopt IPv6 widely for 30 years with very limited success

According to IPv6 – Google, it looks like we’ve gone from ~0% to ~40% in 12 years. IPv6 Measurement Maps has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc

Had the titanic stayed afloat some hours more, many more would have survived and been rescued when assistance eventually arrived. So that makes this a debate over whether this is deck chair re-arrangement or something more meaningful.

As I and others have pointed out, it depends on how it is used. And perhaps the attempt should be made regardless of knowing in advance which it will be.

You assertion needs some back of the envelope numbers, which once provided, I suspect will render your estimate grossly incorrect.

You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.

Especially as we have examples of what that type of effort might look like. IGTFY and here

https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/

The burdensome position is ridiculous even more so when stated with a straight face.

Joe

44

Eric Kuhnke wrote:

In a theoretical scenario where somebody was global benevolent dictator of ipv4 space, even applying a policy which limited block size to a few /14 per ISP, it would be possible to exhaust 240/4/in one week/ if they handed out /14 sized pieces to every existing last mile LTE network operator with 5+ million customers globally. It is not a long term solution or even a good medium term solution.

To to the LM LTE Operator with 5+ mill. customer globally, it is not. Agreed. Also, I think they have already sorted themselves out sufficiently in a variety of ways. I am not concerned with them, at all.

Which is why I did not offer that as an example of useful constraint. Re-run your projections with what I actually discussed, I think you will have a different conclusion.

Joe

45

Of course, Joe, that attitude might also be cited of IPv6 deployment laggards! :wink: i.e., the mumbling of those in the periphery of Internet regarding why they’re not doing IPv6…

(It’s not an issue for those closer to high-growth areas – e.g. mobile and consumer broadband – as IPv6 has become the default with many of them for their new connections – <https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption> )

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

46

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will take any ipv4 resources they can get. They’re all on waiting lists or have been informed no new blocks will be forthcoming.

240/4 is something like 256 million IPs.

Let’s say that the global benevolent ipv4 dictator decides that each ISP, MNO or other waiting list entity gets a single /16, one time only.

That’s 64,000 IPs per corporate entity. Not actually very large at all on the scale of regional mid sized operators with 300,000 last mile broadband subscribers, or mobile network operators, nevermind top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of customers. One /16 is a tiny drop in the bucket compared to the demand for IP space for indivudual-customer DHCP pool usage by an ISP the size of Astound or a South Korean GPON operator or similar.

That’s 4000 entities which each get their one time /16 and then 240/4 is entirely exhausted.

Unrealistic? Halve it so that each network operator waiting for IP space reources gets one/ 17, one time only, I would still bet good money that there’s 8000 ASes out there that right now would happily take their "free "single /17 , and you’d still have immediate complete exhaustion of 240/8.

47

One can and indeed some do attempt to do just that. The likelihood of these attempts actually convincing those in a position to influence change is what is in question.

IMNSHO, if such a proposal were to gain traction, by the time that gear capable of using 240/4 as unicast were to be widely deployed, IPv6-capable gear would be much more widely deployed.

META: Can whoever is doing so please stop creating new time-stamped subject lines for the same topic? It makes things hard to follow.

48

Joe,

As I and others have pointed out, it depends on how it is used.

Sure, and with enough thrust and an appropriate trajectory, pigs fly quite well, although the landing can get messy. With enough constraints, any problem becomes trivially solvable. Whether it is a useful problem to solve is the question.

And perhaps the attempt should be made regardless of knowing in advance which it will be.

You’ll get no argument from me. In the past, I’ve suggested a Cloudflare 1.1.1.1-like experiment would provide useful data.

You can hardly attempt to convince anybody that 240/4 as unicast would not be the more trivial change made in any of these products natural life cycle points.

How trivial would the change be in a product by a company that no longer exists or a product line that is no longer supported? Will Microsoft update all previous versions of Windows? Will the myriad of deployed embedded systems sitting forgotten in closets be updated? And if you’re going to the trouble to update those systems (in most cases, by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.

Regards,
-drc

49

Joe -

In the snippet above you allude to a very important aspect of the Internet that is rather germane to this discussion – ii.e. that we really don’t really have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent” –, but then you don’t really work through what that fact means for realistic outcomes of class E space re-utilization…

First, I want to be really clear: I don’t particular care one way or the other regarding the proposal to “de-reserve” 240/4… I don’t run a network (nor has the ARIN community discussed the matter and directed that ARIN take a position either way.) However, I do think the operator community should be thinking hard about how such de-reserving and redefinition into general purpose space will impact the Internet operations community and whether such space can realistically ever be utilized in production manner in the public Internet.

As you alluded to, we really don’t have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent”, and the practical implications of this fact is that there will always be many devices out there in production that will not pass IP packets with class E addresses in them… (just as there’s always going to be some devices, somewhere that don’t know about IPv6.)

Of course, the difference is that with IPv6 we can attempt a connection and then fall back to IPv4, and further that devices out there either support and are configured for IPv6 routing, or they are not - networks rather quickly learn not to announce (via routing & DNS) IPv6 connectivity for devices without it actually being in place and operational or having solid IPv4 fall-back and relying fast fallback/happy eyeballs.

With your using repurposed class E address space in the headers, your customers with such addresses are rather unlikely to ever know why a connection won’t establish – or why existing connections sometime fail mid-stream – as it only takes a single non-conforming device along the ever-changing path through any number of network operators to resulting in the silent drop of that packet. That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.

If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.

Thanks,
/John

p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.

50

Indeed that is exactly what has been happening since the initial
proposals regarding 240/4. To the extent that it is now largely
supported or available across a wide variety of gear, much of it not
even modern in any way.

As someone who has been involved in the deployment of network gear into class E space (extensively, for our own internal reasons, which doesn’t preclude public use of class E), “largely supported” != “universally supported”.

There remains hardware devices that blackhole class E traffic, for which there is no fix. https://seclists.org/nanog/2021/Nov/272 is where I list one of them. There are many, many other devices where we have seen interesting behavior, some of which has been fixed, some of which has not.

cheers,

lincoln.

51

Much of India operates this way today.

Owen

52

Dear Eric:

1) " ... expecting the vast amount of legacy ipv4-only equipment out there in the world that is 10, 15, 20 years old to magically become compatible with the use of 240/4 in the global routing table ... ": It is apparent that you do not recognize a few unorthodox EzIP characteristics. For example:

A\. The activation of 240/4 netblocks is very scalable\. It can be as small as starting from a residential home as evidenced by our initial realization of this technique via expanding the address pool by 256 folds utilizing 192\.168\.K/24, or as big as or even multiple of 100\.64/4 netblocks that have been deployed all over the places for CG\-NAT\.

B. Since the enhancement to use 240/4 is from the last-mile equipment and up, equipment capable of the program change can be enhanced without coordinating with any router nearby. In fact, they can continue to communicate through the originally established setup. This is a selective incremental process. There is no requirement to upgrade them all at the same time, such as what happened to IPv6. (I hope that you would not tell me that the routers whose programs were modified to handle the 100.64/4 netblocks for CG-NAT operation only about one decade ago are now too old to accept 240/4.)

C. Once a router is enhanced to use 240/4, its original capability set continues with the addition of end-to-end connectivity within an area served by that router. No other routers would know about this change.

D. This gives incentives to other regions to upgrade at their own paces, respectively. Note that we are talking about a generic program enhancement which can be downloaded to routers of the same model series through maintenance update cycles. So, we should not be discouraged by counting how many total routers are out there.

E. Since the first phase of the EzIP deployment is to enhance CG-NAT, there is no expansion of global routing table.

2) "... directly analogous to building sand castles on the beach when the tide is obviously coming in. ": This is the same as "the train has left the station" metaphor that we were told when we first started to look into this issue. So, we decided that our work was just for academic fun. As time went on, however, we learned that the Dual-Stack configuration was not just necessary but also going to last for a long time. Recently, we even heard (see the APNIC blog below as an example) that the IPv4 to IP6 transition may never end. So, I believe that it would be prudent for everyone to focus on improving his/her preferred version. There is no more reason to waste energy in discrediting the other camp's efforts.

The transition to IPv6: Are we there yet?

3) " ... Trying to extend the use of ipv4 space resources for a few more years ... ": Unlike other proposals that we are aware of, EzIP is an enhancement to RF6598 which applies to CG-NAT that is a hierarchical network. Following such a configuration, the manageable public IPv4 pool is extended to roughly 983MB addresses (see the last paragraph of Sub-Section 2.1 in the EzIP Draft). Administrated in the traditional communication system identification discipline and supplemented by RFC1918 netblocks, this resources can last for a really long time.

Regards,

Abe (2022-11-21 22:59 EST)

53

John Curran wrote:

… Further, presentment of options in this fashion presumes that we have some ability to control or decide how engineering efforts across the entirety of the internet should be spent.

Joe -

In the snippet above you allude to a very important aspect of the Internet that is rather germane to this discussion – ii.e. that we really don’t really have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent” –, but then you don’t really work through what that fact means for realistic outcomes of class E space re-utilization…

True

As you alluded to, we really don’t have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent”, and the practical implications of this fact is that there will always be many devices out there in production that will not pass IP packets with class E addresses in them… (just as there’s always going to be some devices, somewhere that don’t know about IPv6.)

To what extent will this be? And to what extent could it have been had this been seriously considered dozen+ years ago? We wont really know until we can get serious about it.

Of course, the difference is that with IPv6 we can attempt a connection and then fall back to IPv4, and further that devices out there either support and are configured for IPv6 routing, or they are not - networks rather quickly learn not to announce (via routing & DNS) IPv6 connectivity for devices without it actually being in place and operational or having solid IPv4 fall-back and relying fast fallback/happy eyeballs.

This is a very fair point. Or perhaps we can have reverse happy eyeballs for IPv4 fallling back to sub-optimal auto-tunneled IPv6?

With your using repurposed class E address space in the headers, your customers with such addresses are rather unlikely to ever know why a connection won’t establish – or why existing connections sometime fail mid-stream – as it only takes a single non-conforming device along the ever-changing path through any number of network operators to resulting in the silent drop of that packet.

I am not that sure about silent, presumably traceroute will be just as (un)usable.

That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.

If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.

Thanks,
/John

p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.

Right now the gossiped growing use of 240/4 in private and non standardized fashions jeopardizes any potential use of it just as much as the factors you describe.

In either event, my main point of contention is in the lack of willingness for serious and prudent consideration. Such as along the lines of what you have brought up.

So thank you.

Best,

Joe

54

Eric Kuhnke wrote:

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will take any ipv4 resources they can get. They're all on waiting lists or have been informed no new blocks will be forthcoming.

240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP, MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on the scale of regional mid sized operators with 300,000 last mile broadband subscribers, or mobile network operators, nevermind top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of customers. One /16 is a tiny drop in the bucket compared to the demand for IP space for indivudual-customer DHCP pool usage by an ISP the size of Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is entirely exhausted.

Unrealistic? Halve it so that each network operator waiting for IP space reources gets one/ 17, one time only, I would still bet good money that there's 8000 ASes out there that right now would happily take their "free "single /17 , and you'd still have immediate complete exhaustion of 240/8.

Right now the IPv4 scarcity is a barrier of entry to new entities and a major speedbump in basic growth to small entities.

So my constraint has much wider, lasting and meaningful impact than either of your thought exercises which essentially involve how to enable existing entities to resume business as usual for some amount of time. I am sure there many other much more meaningful ways to consider using 240/4 than that.

New IPv4 resources to go towards addressing customers in the same fashion as was done ten years ago, I wouldn't bother with 240/4 for that either.

Best,

Joe

55

Lincoln Dale wrote:

56

David Conrad wrote:

Barry,

We've been trying to get people to adopt IPv6 widely for 30 years with very limited success

According to IPv6 – Google, it looks like we’ve gone from ~0% to ~40% in 12 years. IPv6 Measurement Maps has it around 30%. Given an Internet population of about 5B, this can (simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a transition to a technology that the vast majority of people who pay the bills will neither notice nor care about, and for which the business case typically needs projection way past the normal quarterly focus of shareholders, that seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, the fundamental and obvious flaw is the assertion of "commenting out one line code”. There isn’t “one line of code”. There are literally _billions_ of instances of “one line of code”, the vast majority of which need to be changed/deployed/tested with absolutely no business case to do so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has been pointed out numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc

Re-replying. Changing the standards is not what is intended to drive vendor changes. Userbase requests and projected needs do that.

The standards are not responsible for the business case. However, they should not unreasonably impede it.

Joe

57

John Curran wrote:

…

That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.

If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.

Thanks,
/John

p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.

Right now the gossiped growing use of 240/4 in private and non standardized fashions jeopardizes any potential use of it just as much as the factors you describe.

Joe -

That may be the case - I have no data either way, but it would not be surprising if some folks were paying very careful attention to their vendor support of 240/4 routing so that they can use this address space in a private context.

However, I still have not heard any reasonable explanation for how connections using de-reserved 240/4 space in a public scope will be operationally viable, given that there will always be devices which do not forward such packets…

In either event, my main point of contention is in the lack of willingness for serious and prudent consideration. Such as along the lines of what you have brought up.

You have an opportunity now - please explain how such connections will not pose an operations nightmare for the rest of the public Internet – it is not at all apparent how such is avoided if 240/4 is changed from reserved to general purpose (if that’s what you are suggesting that we should be doing.)

Of course the other alternative is what Abe has been suggesting (repeatedly): note that it is not using 240/4 for general purpose address space, but rather for their "Adaptive IPv4 Address Space” <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/> mapping protocol. It seems to suffer from the same assumption of unmolested 240/4 transit in the public Internet (despite the current specification of such addresses as invalid) but then adds some further complication… something akin to CG-NAT but with their new EZ-IP protocol and “semi-public routers” as gateways doing the address mapping function.

I am all for serious discussion of either of these interesting proposals, but if we’re going to seriously discuss such being deployed in the real-world then it had best start with the question of how they will handle the current Internet which frequently drops packets containing 240/4 addresses as invalid and will be doing so in places for many years to come. The upgrades in the real world to address that invalid-drop situation will take quite a while to happen (and note that time starts only after there’s an actual consensus for change in this regard), so – just as it was with IPv6 – it’s incumbent on those proposing change to explain how interoperability occurs during the transition period.

Thanks,
/John

p.s. Disclaimer(s): my views alone - this message made from 100% recycled electrons.

58

As someone who has been involved in the deployment of network gear
into class E space (extensively, for our own internal reasons, which
doesn’t preclude public use of class E), “largely supported” !=
“universally supported”.

There remains hardware devices that blackhole class E traffic, for
which there is no fix. https://seclists.org/nanog/2021/Nov/272 is
where I list one of them. There are many, many other devices where we
have seen interesting behavior, some of which has been fixed, some of
which has not.

And I am sure you would agree that un-reserving a decade ago would have
more than likely resulted in a greatly improved situation now. Along the
lines that doing so now could still result in a greatly improved
situation a decade hence. Should we still need it.

It may well have helped (a decade ago) past-tense, but it isn’t the reality of today.

I’ve pointed out there is a non-zero number of existing devices, OSs, things baked into silicon, even widely used BGP stacks today, that can’t currently use class E, and some of them will never be able to.
You seem to be suggesting that class E could be opened up as valid public IPv4 space. My experience is that it would not be usable public IPv4 address space any time soon, if ever.

I’m not arguing that unreserving it today may address some of that. But it will never address all of it.

cheers,

lincoln.

59

David Conrad wrote:

How trivial would the change be in a product by a company that no longer exists or a product line that is no longer supported? Will Microsoft update all previous versions of Windows? Will the myriad of deployed embedded systems sitting forgotten in closets be updated? And if you’re going to the trouble to update those systems (in most cases, by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is getting all the instantiations of that bit of code implemented, tested, and deployed across all the myriad supported and unsupported systems (both operational and management) that support 5 billion+ Internet users globally in a timeframe and for a cost that makes business sense.

Regards,
-drc

Lets agree to stop conflating the issue of products under active support and refresh cycles with the issue of those that are obsolete and only subject to attrition.

Two different problems areas entirely.

The former, yes it is trivial. An update in standards could yield rapid results here.

The latter takes time. An update in standards could take years to bear enough fruit. All the more reason it should have happened then, all the more reason to let it happen now.

Joe

60

Jay Hennigan wrote:

IMNSHO, if such a proposal were to gain traction, by the time that gear capable of using 240/4 as unicast were to be widely deployed, IPv6-capable gear would be much more widely deployed.

Considering that is already the situation, whats your point?