Re: [OPSAWG] WGLC on shared transition space

[Owen DeLong <[e-mail]>]

On Aug 4, 2011, at 6:12 PM, Matthew Kaufman wrote:

> On 8/4/2011 5:18 PM, Owen DeLong wrote:
>> On Aug 4, 2011, at 4:03 PM, Matthew Kaufman wrote:
>> 
>>> On 8/2/2011 3:13 PM, Brian E Carpenter wrote:
>>>> I have concluded that it is inappropriate for the IETF to endorse
>>>> this hack.
>>> I agree.
>>> 
>>> The "middle" network for NAT444 can be numbered by the ISP with RFC1918 space in all cases except those where the specific block from RFC1918 space conflicts with customer internal use, a situation which can be arranged to be rare and which is easily both detected and fixed if encountered.
>>> 
>> In the case of a residential ISP where they have millions of customers distributed across random pieces of RFC-1918 space, how
>> would you (feasibly) arrange for it to be rare, easily detected, and (feasibly) fixed?
> 
> *Most* "residential" customers are actually in a very tiny portion of RFC1918 space. And the detection strategies range from the various information leakage-before-changeover approaches, like watching their DNS queries, to having customers run software (even from a web page) before you switch them, all the way to my personal favorite: "Dear Customer, your service is about to be seriously degraded by an additional layer of NAT. If you are using <10.99.88.0/24> for your internal network OR you experience a complete outage of your service after <changeover date> please call our support number."
> 

1. *Most* residential customers may be, but, *ENOUGH* residential customers to pose a significant and costly problem are spread
	all over the map. There are some CPE routers out there that default to having the customer choose 10/172/192.168 and then
	pick random numbers to fill in the rest of the blank and/or just use that whole range and default to very sparse DHCP algorithms
	that might as well be random. The collision potential with any range chosen by the ISP is high.

2. You are assuming that having them call the support number is somehow a desirable outcome. When you are charging $20-50/month
	for a service, having 1% of your 10,000,000 customers call in a month (100,000 phone calls) is damagingly expensive.

> 
>> This claim utterly ignores the operational realities of the existing situation, which I and much of the rest of the operational community
>> consider rather a forté of the IETF at this point, but we're hoping to change that through participation.
>> 
>>> If it is desired to never encounter that situation, globally unique space already allocated to the ISP may be used (and reused multiple times if necessary) instead of RFC1918 space.
>>> 
>> It is very much desired to avoid this situation. Sure, 100s or even 1000s of ISPs can do that, resulting in 100s or 1000s of address blocks
>> being allocated to this purpose instead of one. How does that benefit the community?
>> 
> 
> 100s and 1000s of address blocks are already allocated to suboptimal purposes... how is this any different? They're going to run out one way or another. And soon.
> 

I can't think of a better way to indicate that at its worst, this proposal is harmless.

>>> If two or more ISPs wish to agree to reuse portions of one another's space for this purpose, there's nothing stopping that from happening either.
>>> 
>> Other than the operational realities of making ones business dependent on the continued good will and unchanging nature of the needs of
>> some other business with whom you also happen to be a competitor.
> 
> Well, post-runout one of you will probably buy the other, thanks the these same "operational realities".

I don't think that is necessarily true. In fact, it's equally likely that some other party will buy the other and decide that they want those
addresses for a different purpose, vacate my space and tell me to get off of theirs.

>> Again, please step out of the ivory tower for a moment and look at the operational reality for the variety of networks that are all asking for
>> this. It really is in the best interests of the internet to make this happen.
>> 
> 
> It is "a little easier for ISPs"... I would say that this is in the "best interests" of almost anyone else. The end-users who'll find themselves behind another layer of NAT? Nope. The corporate IT departments that will misuse this instead of switching to IPv6? Nope. The ISPs that put content servers here instead of switching to v6 or even just optimizing the use of their existing space? Nope.
> I could go on, obviously.
> 

This will reduce the number of end users who will find themselves behind another layer of NAT, so, yes, it is in their interests.

Even with the proposed and/or identified corporate misuses of this space you described, it would not help them to avoid switching to IPv6,
so, that argument is specious at best. In any case, I really don't think it is the job or mission of the IETF to protect corporate IT from their
own failure to read RFCs.

ISPs that are likely to put content servers here are not likely to do it instead of switching to IPv6, they are likely to do it in parallel to switching
to IPv6, so, again, that argument is still specious.

As to optimizing the use of their existing space, this proposal allows them to do just that (see my response to your first point).

>>> Setting aside a block for this purpose has the following drawbacks:
>>> 1. Reduces the number of rapidly diminishing globally unique IPv4 addresses
>>> 
>> No, it actually increases it because the requests that will result from a denial will far exceed a /10.
>> 
> 
> Doesn't matter either way, really.
> 
Ah, but, actually it does. It won't change the end date, but, it may (dramatically) reduce the number of users on whom NAT444 is inflicted.

>>> 2. Provides a shared block that is known to never conflict with RFC1918 space, and thus will be used for numerous other applications outside of the applicability statement (such as it is) in Section 4 of the draft. For example, corporate network operators will undoubtedly use this space to facilitate VPNs between two different companies that have overlapping RFC1918 space, and may even choose to place intranet servers in this space during merger and acquisition activities. This will then conflict with its use as the middle layer of NAT444 should the company be moved to a NAT444 environment without its knowledge.
>> If they use it that way, they do so knowing full well the difficulties it may cause. There are lots of examples of the misuse of RFC-1918
>> space that have not caused any harm to those other than the ones misusing the space, so, I don't see any reason for this to be different.
> 
> The point is that this particular misuse of the space is such that if it happens, the situation between the customer and the ISP is *no different* than if RFC1918 had been used. You can't argue that RFC1918 won't work *and* that the above outcome is acceptable simultaneously.
> 
While this is true, in the case of RFC-1918, it becomes a pissing contest between the customer and the ISP with the ISP having no
valid leg to stand on for why the customer should have to renumber their internal network. In the case of this space, OTOH, there's
documented RFC reasons why they shouldn't have used it this way.

Additionally, as you pointed out, it's not likely to be the 10,000,000 residential customers that misuse it this way, it's likely to be the business
customers who are:

	1)	A much smaller percentage of customers
	2)	Higher revenue than residential per circuit, generally
	3)	More reasonable in most cases than residential customers

So, while it may be mathematically no different from a purity of the solution standpoint, the economic realities of the two situations are
radically and meaningfully different.

>>> Note that this use case is SPECIFICALLY called out in section 2.1.2 of draft-bdgks-arin-shared-transition-space-00, with no mention of how it breaks the actual intended purpose of the space.
>>> 
>> That's because in 99% of actual cases it wouldn't actually be a conflict. The things in this middle space wouldn't need to talk directly
>> to the ISP NAT network and there would be no conflict as a result.
> 
> You pulled that 99% out of the same place you found the number that tells me that residential users are using "all" of RFC1918, when we both know that most of them are in 192.168.1.0/24.
> 

Actually, surveys conducted to date indicate that far less than 50% of them are in 192.168.1. Perhaps most of your users are on Linksys,
but, that does not mean that is the case nationwide, throughout the ARIN service region, or, world wide. Other manufacturers have different
defaults. No, I did not pull the idea that residential users are using "all" of RFC1918 out of my imagination. There have been studies of the
type you recommended above that have shown that it is not so convenient as that.

While I admit I didn't do an advanced analysis of the numbers, it doesn't take a rocket scientist to realize that corporate VPN endpoints (the things you said would be numbered in this space) are not at all likely to use those numbers as source addresses to talk to the external internet.

>>> Also note that this use case is outside of the scope of the ARIN proposal.
>>> 
>> Which is utterly irrelevant to the IETF discussion.
> 
> Sure. We can take the required restriction to the other list... but the ARIN proposal *is* an appendix to one of the two drafts here, and *is* the source of the addresses. IF the ARIN proposal results in a block that, due to ARIN policy reasons, is unable to be used for this use case then this use case can no longer be a justification for the IETF agreeing to the idea.
> 

Or the ARIN policy can be modified to bring it in line with the IETF document, OR, the address space, since ARIN is relinquishing it to IANA for
allocation according to this RFC and using the policy as the enabling language to do so would not actually be subject to the ARIN policy once
so relinquished, etc.

There are many ways to deal with that discrepancy.

>>> 3. Provides a shared block that is known to not conflict with RFC1918 space that does not "use up" an ISPs globally unique addresses, thus providing an opportunity to continue deploying IPv4 services to customers rather than transitioning to IPv6, thus making this NOT an IPv6 transition mechanism.
>>> 
>> I don't believe anyone is considering this an IPv6 transition mechanism.
> 
> Section 1 of the draft under consideration: "This document requests that an IPv4 /10 be reserved as Shared Transition Space solely to facilitate deployment of IPv6 transition/IPv4 coexistence technologies."
> 

Yes… THIS space is not a transition mechanism. It is an ENABLER for OTHER transition mechanisms.

>> I believe it is being treated as a survival technique to allow operators
>> to focus on IPv6 transition instead of having to devote vast resources to resolving NAT conflicts. We have to keep the IPv4 network running
>> and we have to deal with NAT444 even if IPv6 is deployed for some time. That's the reality we are faced with.
>> 
>> However, I don't think anyone is regarding this as an opportunity to avoid or postpone deploying IPv6.
> 
> Don't believe you. Especially when the other draft specifically calls out the use case of extending IPv4 lifetime by putting content distribution servers in this space (a way for ISPs to postpone deploying IPv6) and extranet servers in this space (a way for corporations to postpone deploying IPv6).
> 
Extending IPv4 lifetime IS NOT the same as postponing deployment of IPv6. Even with IPv6 deployed, there are valid reasons to preserve
certain IPv4 functions.

You are mistaking keeping IPv4 alive for not implementing IPv6. It is a logical fallacy to conflate the two.

IPv4 does not have to die for IPv6 to get deployed.

> Take the use cases out as part of the justification for the request if you don't want the request read this way.
> 

The use cases talk about preserving IPv4. They do NOT talk about delaying IPv6.

>>  I think they are looking to survive long enough to get IPv6 deployed and to keep operating the things that have to keep working on IPv4 that are incapable of doing IPv6 on the customer end of things at least to the extent possible.
> 
> So the emergency they created is my problem... why?
> 

They did not create the emergency and it isn't your problem. You are not harmed by the allocation of this space to this purpose.

>>> Note that this use case is SPECIFICALLY called out in section 2.1.3 of draft-bdgks-arin-shared-transition-space-00, with no mention that it counters the goal of facilitating IPv4 to IPv6 transition.
>>> 
>> It does not counter the goal of facilitating IPv4 to IPv6 transition, it merely makes that process a little less painful.
>> 
> 
> Disagree. It allows transition to be postponed.
> 

It really doesn't.

>>> Also note that this use case is outside the scope of the ARIN proposal.
>>> 
>> Which is still utterly irrelevant to the IETF discussion.
> 
> See above for the reasoning. (Can't rely on that block being available if it is restricted.)
> 
See above for rebuttal to the flawed reasoning.

>>> Additional comments on draft-bdgks-arin-shared-transition-space-00:
>>> 
>> Note that is not the draft that is the subject of this last call. I think everyone agrees there remains work to be done on draft-bdgks, which
>> was hastily put together by the operations community in an effort to convey additional information about the need for this draft to get
>> an accelerated last call and adoption.
> 
> Then I believe we're doing this in the wrong order. How can I possibly comment as to whether or not a block should be set aside if there's not yet been last call on a document describing how that block would be used?
> 
> I have hypothesized above about what it might be used for, and pointed out that at least two of those are bad ideas. But it'd be even better to get the actual usage documented before we rush this through. I'm sure ARIN can hold the /10 if that's what it takes.
> 

That document is largely informational in nature. This document actually provides the limitations and restrictions on the use of the space and it's purpose for issuance.

> 
>>> Section 2.1.3: The "care must be taken" is impossible. ANY multihomed customer will be negatively impacted by an overlap in address space exposed by their upstream provider.
>>> 
>> Yes. Thus, care must be taken to avoid an overlap that has impact.
> 
> And this is different than just using RFC1918 instead of allocating a new /10 how?
> 

This particular aspect is not. However, of the millions of subscribers on the average large residential provider network, as has been recently
pointed out to me, very very few of them actually multi home. So, it differs in the implementation details due to the difference in the type and
magnitude of the afflicted audience.

>>> Section 2.2.2: The converse of "default behaviors... which may not be desirable" is not mentioned. For example, a node seeing such a shared address will assume that it has a globally unique address rather than (correctly) assuming that it is behind a NAT device. 6to4 and several peer-to-peer protocols would exhibit this incorrect behavior. This is addressed in 4.1.2, but not referenced here.
>>> 
>> They will ALSO exhibit this behavior if providers use and reuse their own GUA space. The difference is that with this shared block, it will be possible, maybe even feasible for software updates to incorporate it into the shared address perspective. Without this draft, the random assortment of address blocks used would make such a mitigation of this issue impossible.
>> 
>> Thus you have just made an excellent argument in favor of this draft.
> 
> I've made an excellent argument in favor of accelerating, not postponing, the transition certainly.
> 

When you have a machine capable of going faster than the speed of light, let me know. In the meantime, let's stick to reality. The transition
isn't going to accelerate enough to make the difference required here. As much as I would like to see that happen, it isn't realistic.
Since meaningful acceleration is not realistic, we have to look at what can actually be done to mitigate and address the realities we
are faced with.

>>> Section 5.1.1: Correctly notes that the question has been asked, and answered in the negative, even in the recent past... I suppose we'll just get the same thing requested at more and more frequent intervals until either it finally passes or there's no /8 or /10 or whatever left to allocate.
>>> 
>> Since there is such a strong operational need, you are correct that the request is unlikely to go away. Given that ARIN has agreed to hold addresses in reserve in support of the ARIN policy (which did achieve consensus) until such time as the IETF/IAB takes appropriate action to make it available, I believe that your statement would be more accurately:
>> 
>> This will keep coming back until it either passes or until IPv4 is well on its way to being decommissioned and it becomes moot.
> 
> Well, last I checked it wasn't appropriate to just keep trying to push the same thing through that has been repeatedly rejected, and with good associated reasons. If the IETF allows this, it will open the door to hundreds of other resubmits of equally bad ideas that have been previously rejected.
> 

I don't see how a body that is governed by the consensus of those that show up can avoid it. The reality is that as this becomes more  and more critical to the operational community, the nature of who comes to the IETF asking for this will continue to evolve until there is enough operator focus on the IETF that there is no alternative.

Owen