Re: [RRG] NAT-PT and other approaches to IPv6 adoption - Dual Stack Lite

[Robin Whittle <rw@firstpr.com.au>]

Hi David,

Thanks for continuing this conversation, in which you wrote:

>>> I don't believe RRG is assuming IPv6-only.  I believe RRG is
>>> assuming dual-stack with (at least) a more scalable IPv6 routing
>>> infrastructure that may also be applicable to IPv4.
>>
>> Dual-stack doesn't help the IPv4 routing scaling problem at all.
> 
> True.  It doesn't hurt it either.  The protocol being used is a bit
> orthogonal to whether the routing system scales.

I agree that this is probably the basis of the RRG's rough
consensus.  I was just observing that it does nothing to help with
the IPv4 scaling problem until such time that it leads to people
being able to rely on IPv6 so much that they can happily do without
IPv4 addresses.


>> Every end user still needs an IPv4 address.
> 
> Well, every NAT would still need an IPv4 address.  But this is also a
> bit orthogonal to whether the routing system scales.

Every residential and office end-user needs a single IPv4 address in
order to be able to run the full set of applications that a
substantial proportion of users are currently used to running.

This is one reason for the consumption of IPv4 addresses, and why
solutions such as Dual Stack Lite will be hard to sell unless they
somehow support port forwarding the way current services do.

The IPv4 scaling problem would still exist without the shortage of
address space, but the shortage of address space will make the
scaling problem much worse than it otherwise would be in the next
five years due to the need to slice up existing space into more and
finer pieces (as separately advertised BGP prefixes) in order that
more and more of the space goes to organisations which need it.


> What matters in routing scalability is how addresses are aggregated. 
> You can make IPv4 or IPv6 scale or not depending on how the addresses
> are allocated and announced to the routing system.

The map-encap, translation and now my Ivip6 proposals all seek solve
the problem by having most end-user prefixes in the future not
individually advertised in the BGP core, while providing the
portable, multihomable, space which many end-users want and need.
Then, it doesn't matter how poorly the provider prefixes are
aggregated, because there won't be so many of them to constitute a
serious scaling problem.

(There also needs to be Mapped Address Blocks - MABs - advertised in
BGP, each containing thousands of micronets.  This is necessary for
the Open ITRs in the DFZ to support hosts sending packets from
networks without ITRs.  These MABs need to be not so numerous as to
overly burden the BGP system so they need to be generally large
enough to cover the micronets of thousands of end-user networks.)


>> Only when large numbers of end-users are on IPv6-only services -
>> including perhaps a service which uses special NAT arrangements to
>> share one IPv4 address with multiple end-users - will IPv6 be able
>> to help reduce the IPv4 scaling problem.
> 
> Not necessarily.  You seem to be assuming IPv6 will be allocated in ways
> that promote aggregation and/or address recipients won't announce more
> specifics of the blocks they received from their allocators.  If (as is
> the current trend at all RIRs) IPv6 addresses are assigned as "provider
> independent", we'll have recreated the non-scalable IPv4 swamp.  Yay us.

I agree.  I was assuming the the RRG efforts would solve the IPv6
routing scaling problem in time, but would not involve a fix for the
IPv4 scaling problem.


> Currently, IPv6 is additive to the size of routing system, that is IPv6
> routes do not displace IPv4 routes.  As such, it exacerbates the routing
> scalability problem.

I think they are two separate problems.  IPv4 is a problem with 260k
advertised prefixes and IPv6 is nowhere near a problem with only a
thousand or so.


> [Alain's "dual stack lite"]
>
>> This is clearly unsuitable for many customers who make extensive use
>> of Bittorrent etc.  I assume that P2P applications only work
>> properly when they can use uPnP IGD to get a public port so they can
>> accept incoming communications from other such programs.
> 
> I haven't been following the P2P stuff particularly closely but my
> understanding is that there are a common set of conventions that allow
> P2P applications to bypass NATs.  This would be what I would expect:
> applications will evolve to meet the constraints of the environment they
> must operate in to be successful.  If the preponderance of networks an
> application will be used in sit behind NAT, then the application will
> have to cope with NAT or no one will use it.

Yes, but I think that mechanism is uPnP IGD to request a public
port.  If not, then Alain wouldn't be so concerned about the
restrictions "Dual Stack Lite" places on a substantial proportion of
ordinary users who like Bittorrent etc.


> And gee, from Comcast's perspective wouldn't it be just horrible for
> Comcast (you know, the folks who just got slapped by the FCC because
> they were trying to stop P2P from sucking up all their upstream
> bandwidth) if P2P stuff didn't work anymore?

Yes - as long as customers had an alternative, it would quickly get
around that Comcast sucks, at least in respect of popular P2P apps,
and anyone who wanted to get a public port to run a gameserver or
whatever else.

Actually, it is a nice little informal protocol to enter "xxx sucks"
  into Google and see what turns up.  30,800 pages for "Comcast
sucks" - but they have a huge number of customers, most of them
presumably happy.


>> I don't see how such a service could be marketable, since it does
>> not suit a significant proportion of end-users.  The marketing would
>> have to be very careful so as not to promise too much.
> 
> Not promise too much?  This is a type of marketing I'm not familiar
> with. (:-))

OK - I admit your point . . .


>> I believe there is a lot of scope for better utilization of IPv4
>> space, so I think we are a long way from the state of affairs where
>> Comcast and their competitors can't scrape together enough space to
>> offer the service that people are used to getting.
> 
> Given someone from Comcast is proposing "dual stack lite", I suspect you
> are underestimating the situation Comcast believes they're facing.  For
> example, while it is very clear that IPv4 address utilization efficiency
> can be greatly increased, the question is how do you incent folks to be
> more efficient.  This gets into religion and questions of address
> allocation policy that I suspect we don't want to get into here.  If
> you're interested in this sort of thing, I'd recommend ppml@arin.net
> (and/or seeing a therapist).

Actually, I am trying to give up PPML.


>> My conclusion is that this sort of service is going to be difficult
>> or impossible to sell as long as customers can choose between it and
>> a competing service with a unique IPv4 address.
> 
> As you know, the free pool of IPv4 address space is projected to run out
> in 2011 (last I looked).  My guess is Comcast (et al.) will change their
> default allocation to their new customers.  The vast majority of
> customers most likely won't notice.  Those that do will likely be given
> the option of purchasing "SuperDuperPowerBooster(tm)" (or some other
> marketing term) for an additional (say) $9.95 a month which will grant
> them a dynamically allocated IPv4 address that can be used for NAT.

I don't have time to research how many people use Bittorrent etc.

My point is that the lack of uPnP IGD is apparently a serious
drawback to Comcast's plans, so I assume it would impact a
significant number of ordinary users, such as 20 to 70%.


>> The IPv4 Internet has a routing scaling problem which has been
>> recognised for years.
> 
> Since IPv6 currently uses the same routing technology as IPv4, the
> _Internet_ has a routing scalability problem.  

These are two separate Internets.

If they were the same Internet, it would be possible to communicate
freely from from an IPv4 host to and from an IPv6 host.  This is not
possible, because they are two separate networks which do not
communicate, except indirectly for some protocols by ALGs and via a
handful of protocols such as email which work the same on both networks.

> The symptoms of that
> problem are most apparent in IPv4 because that is where the vast
> majority of prefixes come from, however the benefit of fixing IPv4
> routing is merely enabling further penetration of (potentially
> multi-layer) NAT.  And if we're doing that, then what's the point of
> deploying IPv6?

I think the benefit of fixing IPv4 routing is primarily that a
billion or more people can continue for the foreseeable future using
the Internet the way they do today.  The Net is an enormously
valuable thing, not least for the interpersonal connections it
enables - and for being a hard-to-resist support system for
democratic reform movements who are opposed to despotic governments.

There is no prospect of moving everyone to IPv6 as far as I can see
- it is too disruptive.  Maybe that would be the best thing for
everyone to move over soon - viewed in some long-term perspective by
the billions of people themselves at some time in the future.
However it would be exceedingly disruptive to do it now, and
virtually no-one wants to do it.


>> One attractive arrangement might be for businesses to get a single
>> IP address, or just a few, and multihome them via DSL and some other
>> mechanism for backup - such as HFC cable or WiMax.  Then they run
>> their mailserver, NAT boxes etc. on that one or a few IP addresses.
>>
>> The only way they will be able to do this scalably, or affordably,
>> is with a little portion of address space - sliced and diced by
>> map-encap.
> 
> If businesses are sitting behind one or two addresses (e.g, a NAT and a
> public service machine), then the addresses can be 'provider
> aggregatable'.  Multi-homing of the kind you describe can be done with
> "Stupid DNS Tricks" without burdening the routing system.  You now have
> an InterNAT that scales to O(2^32) end points.

I am sure Bill Herrin could write a counter argument to this.

It is not my understanding of what people want and need with
multihoming - which is one or more stable IP addresses.  If what you
write was the case, then we wouldn't be here on the RRG trying to
devise a scalable architecture which supports multihoming with
stable IP addresses during the failure event.


>>> One possible scenario to address this: as IPv4 continues to
>>> get sliced and diced, ISPs will be forced to start deploying more
>>> and more draconian filters in order to keep their routers from
>>> falling over/converging in reasonable time-frames.
>>
>> Do you mean refusing to accept some subset of the routes they
>> currently accept?
> 
> Yes.
> 
>> I think this is an unlikely scenario.
> 
> We've been here before, circa 1996.  Some of still have the t-shirts. 
> We have an empirical proof that ISPs will do what they feel necessary to
> protect their own infrastructure including filtering long prefixes. 
> Some argue that such prefix length filters are unstable, that commercial
> pressures result in a tendency to remove the prefix length filters.  My
> view is that there is a tension between operators and sales folk.  As
> routers get upgraded, sales folk win battles and prefix length filters
> are relaxed.  As routers fall over, operators win battles and the prefix
> length filters are put back in.

I stand by all my arguments against the notion that ISPs will start
disconnecting their networks from certain portions of the Net, due
to marginal expense problems with running DFZ routers, due to desire
to urge people to use IPv6 or for any other purpose.


>> There is no way ISPs are going to cut off connectivity to any prefix
>> which their customers actually want to access.
> 
> How many routes do you think a typical end user customer of an ISP like
> Comcast or NTT need to see?  I figure (with no actual data) that the
> typical end user accesses a minute fraction of the 250K routes.  Yes, a
> few customers will be unable to reach their pr0n and will whine.  If
> enough customers whine about the same prefix, the ISP will undoubtely
> allow the route.  If only a few people whine, the ISP can then say to
> those few customers "pay an additional $10/month and will let that route
> through".  This would lead to a natural incentive for folks to figure
> out ways to not pay the 'long prefix surcharge', including potentially
> deploying IPv6.
> 
>> I am sure this scenario would never occur.
> 
> :-)
> 
> http://markmail.org/message/i6ckia4vhsy5duql

OK: I am sure this scenario would never occur in the future to any
significant degree in a situation where customers had a choice
between an ISP who did this and one who didn't, which is typically
the case.

  - Robin

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg