[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

Mark Smith ipng at 69706e6720323030352d30312d31340a.nosense.org
Fri Jan 21 07:24:11 EST 2011


On Fri, 21 Jan 2011 02:17:35 -0800
Owen DeLong <owen at delong.com> wrote:

> 
> On Jan 21, 2011, at 1:31 AM, Mark Smith wrote:
> 
> > Hi William,
> > 
> > On Thu, 20 Jan 2011 16:22:22 -0500
> > William Herrin <bill at herrin.us> wrote:
> > 
> >> On Thu, Jan 20, 2011 at 4:10 PM, Mark Smith
> >> <ipng at 69706e6720323030352d30312d31340a.nosense.org> wrote:
> >>> Why should the global Internet community (i.e. the end-users of
> >>> the Internet) have to help wear the costs of individual ISPs not
> >>> deploying IPv6 quickly enough?
> >> 
> >> Hi Mark,
> >> 
> >> It seems to me that "whose fault is it?" matters less than "what do we
> >> do now?" What we do now is lessen the transition problems (so that the
> >> end users don't get screwed in the short term) while moving forward on
> >> the transition as quickly as practicable (so that the end users don't
> >> get screwed in the long term).
> >> 
> > 
> > They're going to get screwed regardless in the short term because IPv6
> > hasn't been deployed. NAT444 is going to be bad what ever address space
> > is used between the LSN and the customer CPE.
> > 
> This has a lot more to do with content not being accessible on IPv6 and
> not having a solution for IPv4-only customer devices to reach IPv6
> content than it does with the access networks not deploying IPv6.
> 
> The access providers generally agree that native IPv6 or 6rd can be deployed
> easier and quicker than NAT444 for the problems that can solve.
> 
> The difficult comes when they deal with users, even users that have IPv6
> access, that need to reach IPv4 content for whatever reason. This is where
> NAT444 is pretty much the only viable alternative currently on the table.
> 
> I will note that even the people asking for this /10 are saying that they
> really don't want to use it, but, they don't see any alternative.
> 

Maybe they need to be a bit more creative then. I've been thinking of
and on about how to deploy LSN for a few years, and I've been assuming
sharing existing ISP address space. The biggest issues I see right now
are how to manage, control and record port range allocations, as the
supposed CGN functionality on the platforms I'm working with appears to
have no knobs for these things. Recovering and recycling addresses is
an just unavoidable part of the process of introducing address sharing.

> > The proposal doesn't mention another source of unique IPv4 addresses
> > that could be used for this purpose - the ISPs' existing assignments.
> 
> That's really a non-starter.
> 

Why not? 

> > It'll be functionally equivalent to a NAT444 /10, and will preserve
> > more of the remaining public address space for purposes where truly
> > globally unique IPv4 addresses are necessary. It would mean ISPs would
> > have to start sharing their existing addresses sooner rather than
> > later, but that is better for the customers - the longer that ISPs avoid
> > introducing address sharing, the larger the shock to customers when the
> > ISP can't avoid it any longer and has force customers to share
> > addresses all at once. A gradual address sharing roll out would be far
> > better than an abrupt one, for both the ISP and it's customers.
> > 
> You're joking, right?

No.

> This sounds great unless you're one of the lucky
> ones that gets to go first, or, were you volunteering?
> 

So you have a better alternative? I don't like the idea of switching a
whole customer base over to shared addresses and LSN at once, and I
doubt ISP helpdesks will like it either once the inevitable stampede of
calls from a percentage of customers starts coming in all at once.
Easing customers onto it would be a better approach. Netflow based
analysis to identify customers who've set up NAPT port forwards for
common ports might be a good way to start forming a list of customers
who haven't setup port forwards, who'd then become initial candidates
to switch to address sharing.

> > (I'd think in principle if ARIN reserve a NAT444 /10, then the other
> > RIRs would be expected to reserve a /10 or similar size in their region
> > - the proposition doesn't say if the ARIN space would be usable in other
> > regions. Assuming all chose a /10, that means 5 x /10s of public
> > address space going in one fell swoop ...)
> > 
> That's absurd. If any registry reserves a /10, I'm sure all the registries will
> encourage their members to use that /10.

Hopefully so.

> To the best of my knowledge,
> there are no plans to submit this proposal to any other registries (and
> I talked to the proposal author about it the day before yesterday in
> person).
> 

Apparently it was originally proposed to APNIC and rejected, then
the IETF and rejected, and now ARIN. It's being shopped around. As I
said before, I don't understand what the problem is with ISPs using
their own space, so this proposal smells a bit like a way to
"greenfield" a NAT444 deployment, using new address space, instead of
recovering and recycling their own address space. It doesn't make the
function of sharing addresses any better, and it certainly doesn't
prevent address sharing being inevitable once the RIRs run out of
global address space. It reduces the work these ISPs have to do, with
those avoided costs instead being borne by the people who in the future
would have had a legitimate and greater need for space in the /10 that
has now disappeared.

> I think in principle, you really can assume that the RIRs are not insane
> and won't commit wanton acts of destruction on the community.
> 

I'd think so. I thought it may be plausible because the might be
rules against one RIR making recommendations on the use of other RIRs'
address space.

> On the other hand, what I think you will see if this policy does get bogged
> down is a situation where many of the larger providers that are asking
> for this will each go apply for their own allocations and they may or may
> not coordinate sharing that with others. I think that is a far less desirable
> alternative than getting this policy through.
> 

I'm all for that. They'd be paying for those allocations even if they
are sharing those costs amongst each other. For those other providers
who don't need addresses for that purpose, there'd be no externalised
costs that they've had no choice in bearing.


Regards,
mark.


> > Regards,
> > Mark.
> > 
> > 
> >> Do you disagree?
> >> 
> >> 
> >>> Helping ISPs avoid those costs turns the
> >>> situation into one of a Moral Hazard. It won't encourage IPv6
> >>> adoption; it'll delay it because both the incentive to do so, and the
> >>> consequence of not doing so, are reduced.
> >> 
> >> Shall we encourage the patient not to hurt himself by setting the bone
> >> but refusing him pain medication? Sounds positively monstrous to me.
> 
> I find myself having to agree with Bill here. I'm not 100% convinced this is
> the right thing to do, and, I was pretty opposed to it from the understanding
> I had of the issue when it was presented to IETF. However, at this time, I'm
> leaning more towards the belief that this is one of the three things in the
> IPv4 end game that we really need to just hold our noses and do.
> 
> (The first two were NRPM 8.3 and the policy for 6rd)
> 
> Owen
> 
> 



More information about the ARIN-PPML mailing list