Short version: The number of routes in the IPv6 DFZ is about 1/90
of number for IPv4, but has a faster doubling time
of only ~1.5 years.
Summary of why I think TTR Mobility is the only
approach to global mobility which could work (with
the possible exception of IRON).
While Wes is right to expect running code and full
documentation of any proposal he would consider
seriously, unfortunately it looks like I won't have
time in the foreseeable future to develop the Ivip and
TTR Mobility documentation as well as I would like
to, or to write detailed protocols or code.
Growth in the DFZ routing table is not the primary
routing and addressing scalability problem. The more
pressing problems are:
1 - The need for global mobility (IPv4 and IPv6)
for billions of hand-held devices.
2 - The need for millions, tens of millions or
whatever End User Networks (EUNs), including
many SOHO and some purely residential networks,
to have their address space portable and
multihomable, in a scalable manner.
Hi Wes,
Thanks for your message (msg07607) of 24 November. Sorry about my
delay in replying. You wrote:
>> But giving every cell phone a global unicast IPv6 address, via any
>> means, including especially a mobility system which means the device's
>> applications use the same IP address no matter what access network
>> they are using, would enable each device to do direct VoIP to any
>> other IPv6 device. That would reduce the wireless networks to
>> providers of IP connectivity, since it would be trivial to have a VoIP
>> application on the cellphone which communicated directly with the
>> stable (portable and usable via all access networks) IPv6 address of
>> the correspondent device. (Phone numbers would be replaced by IPv6
>> addresses - or by DNS entries for these addresses.)
>>
>> I am not sure there is an impetus for 3G operators to do this, since
>> it would enable many people to bypass their voice services, which are
>> presumably charged for at a higher rate than whatever they would
>> charge for the VoIP packets.
> [WES] Welcome to my nightmare and the resulting paradigm shift about to hit
> the mobile industry. IP bit carriage is already becoming a commodity on the
> wireline network, as services are primarily over the top. The ISP is
> becoming today's power company. We don't care where the power comes from, as
> long as you deliver it reliably and cheaply. The challenge is to make money
> in said commodity business, which means driving out costs. Mobile operators
> may protest and kick and scream, but given the bill of goods that they're
> selling - ubiquitous access to the "cloud" and high-bandwidth, always on
> applications (that are provided by a third party) on new fancy devices that
> go well beyond a telephone, the days of a walled garden are numbered, at
> least in my opinion.
> Never mind the fact that there are incentives to keep mobile to mobile
> traffic as local as possible, rather than carrying it back to some anchor
> point and back out to the same tower. Even if there are still gateway and
> setup functions provided by the mobile carrier, end to end connectivity has
> benefits.
Yes - I think the most important thing is not what is convenient for
cellphone network operators, but the fact that people want to be able
to do anything anywhere, to any host, and are prepared to pay for it
rather than stay in a single carrier's walled garden.
>> To use TTR Mobility, you don't need new routers. You, or someone
>> else, needs to develop a bunch of protocols and software to implement
>> them. The ITRs, ETRs/TTRs and mapping system can all be done with
>> COTS servers. These functions don't need to be done by Cisco/Juniper
>> routers. You would also need to develop tunneling and management
>> software for each particular type of mobile device your customers use.
>> Assuming your routers, mobile networks and mobile devices can do
>> IPv6, it "just" needs a lot of software development. Competent
>> programmers could figure it out from reading the TTR Mobility and Ivip
>> stuff. You don't need to wait for the IETF. Hopefully my exposure of
>> this stuff means none of it can be patented - or that such patents
>> would not hold up in court.
> [WES] Well, ultimately that's true of a lot of these proposals, that
> competent programmers could build an implementation and no one needs to wait
> for the IETF. However, I'm not a programmer, and I don't have a passel of
> them at my disposal nor the funds to bankroll them, so it ends up falling to
> those who came up with the idea to seek support among like-minded folks,
> either in the research or vendor development community to get an
> implementation stood up as a proof of concept. So much like many inventions,
> the key is now to convince some "investors" to help you implement so that
> you can show how good of an idea it is, instead of just being convinced of
> it yourself.
I agree. I don't have time to implement Ivip and TTR Mobility on my
own. I figure over time other people will take an interest in these
in the IETF and/or some company will want to develop a working system
for themselves, independent of the IETF.
It would be radical and probably inadvisable for a company such as
Sprint to take on the development of such a system, especially since
the principles are public and hopefully can't be locked up in patents.
All I am saying is that these approaches are worthy of consideration
and that I argue they are the only ones which pass muster, given the
failings of other approaches to mobility:
1 - I think Ivip with TTR Mobility can do what is needed: a scalable
approach to global mobility, with the existing host protocols,
for IPv4 and IPv6, with minimal activity by the mobile node or
anything else every time the MN gets a new CoA - and with
generally optimal path lengths.
2 - Your hope of application and stack programmers adapting their
work to any new host protocol has absolutely zero chance of
coming to fruition. The existing host protocols are perfectly
good and are more efficient than Loc / ID Separation:
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
Trying to write and debug apps which work with and without
updated stacks, with other apps which may or may not be updated,
would be a nightmare.
3 - ILNP and other Loc / ID Separation architectures all involve
changes to host stacks and applications - and are only
potentially practical for IPv6. They only provide genuine
scalable routing benefits and benefits to adoptors once every
other host uses the new architecture. Until then, every host
stack and application would have to work well in a mixed
environment of current protocols and the new one - this would
be such a headache that I can't imagine how it could be done.
4 - The Loc/ID Separation approach to Mobility, and the LISP-mn
approach, both involve correspondent hosts and the mapping
system being sent secure updates, by the MN, every time the MN
gets a new locator (or CoA for LISP-mn). Since changes to CoA
could happen every second or so, this is never going to be
practical. Only TTR Mobility solves this problem while still
providing generally optimal path lengths - the MN makes a new
tunnel to the currently used, typically nearby, TTR. There's
no change to mapping and the correspondent hosts don't need to
know of the MN's new CoA at all.
5 - TTR Mobility could be used with LISP, but Ivip would be a better
choice. (I haven't read the latest IRON drafts, but I
understand it uses some TTR Mobility principles.)
>> There's no way the IPv6 DFZ routing table is going to become
>> too large for your routers in the foreseeable future - say in the
>> next 10 to 15 years. (Unless the limitation is the total number
>> of IPv4 and IPv6 routes - in which case the problems can't be
>> separated and my analysis would be different.)
>
> [WES] Many modern routers no longer specify IPv4 vs IPv6 in their scale
> targets because they assume you'll be running both. They talk about the
> entire routing table, and if there are things like TCAM or memory slots,
> IPv4 takes one slot, IPv6 takes two, so it's dependent on how many of each
> you have together. Sure, running single stack will improve the scale of the
> one routing table considerably, but it's still a finite resource. Keep in
> mind that many edge routers are also holding huge L3VPN routing tables (as
> big as or bigger than the global table), so some may realistically be
> nipping at that magic 1M route threshold in a year or two.
OK - it is my impression that the IPv4 DFZ routing table is a
significant burden on routers, but far from the only one. If there
was a situation where a large proportion of ISPs' routers would
suddenly be unable to handle every advertised route (of /24 and
shorter) in IPv4, when the number got to, for instance, 500,000
routes, then there would be a more unified sense of alarm amongst the
ISPs about this aspect of the routing scaling problem.
As far as I can tell, there's no sharp relationship between the number
of routes in the IPv4 DSP and significant increase in difficulties for
any one ISP or for all of them. So its a "boiling the frog slowly"
scenario where the incremental short-term cost of accepting the
increasingly worse situation is generally less than taking radical
action to fix it globally.
>> The only scaling difficulty would arise if there were
>> lots of end-user networks (EUNs) wanting, getting and advertising
>> their own IPv6 PI prefixes AND if you really wanted or needed to
>> exchange packets with those EUNs. There would need to be a lot of
>> such EUNs doing this before the problem got to the 200k, 300k, 600k
>> or whatever level where I assume you begin to hit limits with the
>> routers.
> [WES] Unfortunately that's exactly what is happening. Every time I turn
> around, especially in the RIR community, the refrain is "renumbering sucks,
> we have plenty of IPv6 space, so give me PI space so that I don't have to
> ever do it again, even (especially) when I want to tell my upstream ISP to
> get stuffed." Further, in an attempt to make IPv6 deployment as attractive
> and easy as possible, RIRs are always toying with some new idea about how
> they might make it easier for people to get PI space, up to and including
> proactively assigning a block to every ASN in the table. Those who bring up
> concerns about routing table slot usage are usually handed the old chestnut
> "$RIR doesn't create routing policy, we just assign addresses, so that's not
> our concern."
'Once the rockets go up, Who cares where they come down?
That's not my department,' says Werner Von Braun!"
Still, my point is you would need a *lot* of EUNs to do this before
the problem got to the scale of the current IPv4 DFZ routing table.
http://bgp.potaroo.net
330k routes. Doubling time ~5 years
http://bgp.potaroo.net/v6/as2.0/index.html
3.7k routes. Doubling time ~1.5 years . . . Hmmm
I agree the IPv6 rate is a lot steeper. If the doubling time gets to
1 year, that will take just over 6 years to get as bad as IPv4. If it
stays at 1.5 years, it will take 11 years. This is different from the
1k routes 4 year doubling time of three years ago.
> Even if we stay with PD, multihoming and TE mean that deaggregation is
> pretty much expected. I agree that the growth rate will be less than with
> IPv4, but it's still a consideration. If anything, it just gives us a more
> realistic timeframe to get a fix implemented, rather than resetting the
> clock for when we should start worrying about it.
I agree - I guess you meant "PI".
>> That growth in EUNs advertising PI prefixes has nothing to do with
>> mobile or DSL/fiber access networks, even with billions of
>> customers. You might have part of your 3G/4G network supporting
>> 50 million customers, each with one device. But it will only
>> involve one or a few prefixes in the IPv6 DFZ. So I can't see how
>> 3G/4G ISPs alone will ever cause the IPv6 DFZ routing table to
>> grow to a problematic size.
> [WES] There's some truth to that. However, as I've mentioned here before,
> this scale issue does go beyond the DFZ, and when you start looking at the
> amount of routes you carry internally prior to being able to announce that
> aggregate to the rest of the DFZ, the design and how much aggregation you
> can do regionally becomes a concern.
OK - but that is a private matter for each ISP. Its not a burden
forced on every ISP which wants to participate in the interdomain
routing system - and all ISPs must.
While this whole RRG project started largely on the basis of alarm
about the growth in the "DFZ routing table" size (number of routes in
the IPv4 and later IPv6 interdomain routing system, most of which are
from EUNs wanting portability and multihoming) I think the more
pressing concerns are:
1 - The pressing and potentially very profitable need for global
mobility, with a single stable IP address (or /64 for IPv6)
for billions of hand-held devices.
2 - The inability of many EUNs to get the portability and
multihoming they want (at all, or in a scalable manner - since
getting PI space and advertising it in the DFZ is not scalable).
This extends to potentially tens or hundreds of millions
of EUNs. For instance, in Australia, a "National Broadband
Network" is now being created. It will be funded at vast
expense by taxpayers and be an admirable PON network, operating
as a wholesale carriage provider, with ISPs using it to deliver
their retailed services. The plan involves mandatory closing
down of copper (DSL) and cable (HFC) Internet services wherever
the NBN is installed. (!!!!)
Let's say someone puts a backhoe through a bundle of fibres so
my home-office network is dead for a few hours or days. I want
to be able to use a 3G cellphone service, with a dynamic and/or
NATed address, for my network - so I want to be able to
multihome my current single IPv4 address patch of space. (Or
maybe use a WiFi link to someone on the other side of the valley
who still has fibre connectivity.)
In this context, the question of the number of routes in the IPv4 or
IPv6 DFZ is not the central scaling problem in routing and addressing.
>>> Having to evaluate running code and make a choice between multiple
>>> different options that exist in the output of this group is a
>>> problem that I would very much like to have, and I see no way that
>>> revisiting arguments that you've apparently been having with this
>>> group since 2007 gets us anywhere closer to that goal.
>>
>> Its counter-intuitive that valuable solutions might come for free from
>> some bloke in Australia you haven't met, rather than the Cisco or
>> Juniper folks who you have paid millions or billions of dollars to for
>> their essential and generally excellent routers. But until someone
>> shows that my proposals contain fatal flaws, this counter-intuitive
>> notion hasn't been disproven.
>>
> [WES] It's not counter-intuitive. Vendors didn't always rule the IETF, and
> many good ideas are the result of "some bloke." However at this point,
> running code is the method by which to prove or disprove any of these
> implementations, as I would hope that people far smarter than me have
> already looked at these in great detail over the last 2-3 years and
> identified the theoretical issues and corner cases and potential fatal
> flaws. Put simply, it's been debated to death now, and I expect that you've
> refined the basic design as much as you will be able to as a result of those
> conversations.
I still have more work to do on it, but I don't have time to rewrite
everything as well as I would like.
> Everyone on the list who maintains that an identified flaw in
> a given implementation isn't actually fatal and that critics just need to
> understand the implementation better can be vindicated by showing test
> results from a sample implementation, no matter how rudimentary.
Ideally I would be able to do this. Maybe in a few years' time. In
the meantime, other people may take an interest in these ideas and
develop their own protocols and their own code.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
