[ppml] Re: [address-policy-wg] Is the time for conservation over?

[Michel Py]

Owen,

>> Michel Py wrote:
>> No, it has nothing to do with IPv6 and everything to do with
>> geographical spread. If you are a multinational organization, you
don't
>> want to announce your address space in one piece. You have allocated
>> some addresses to east coast, some to west coast, some to Europe,
some
>> to china, some to Australia, etc. So you announce more than one block
to
>> achieve global load balancing and avoid transporting traffic
internally.
>> Today, large organizations that would want to deploy IPv6 have only
one
>> option: lie to their RIRs pretending they are LIRs and obtain
multiple
>> /32s.

> Owen DeLong wrote:
> Sorry... If you want to do that, you have multiple autonomous
> systems. The definition of an autonomous system is a collection
> of routes with a consistent routing policy.  If you are
> announcing some from east and some from west, etc. and don't
> want to provide a backbone between, then, you are dealing with
> an autonomous system for east and an autonomous system for west,
> etc.

I see your point. Let me ask you this: I am a multinational organization
(non-ISP). I have offices all over the world including in New York and
Hong Kong. In New York, I buy transit from ISP A and ISP B. In Hong
Kong, I buy transit from ISP C. (the reasons I don't buy transit from
ISP A in HK can be diverse: maybe ISP A's network in Asia stinks, maybe
they give me a good deal in the US but not in HK, etc). Should I need
multiple ASes for this? And even if you say so, convince me why I should
listen to you when a single AS is so simpler for me.


> This also assumes that the majority of large organizations don't
> want to transport traffic internally (I don't know how true/false
> this assumption is for various organizations).

Not when they can avoid it, this is a matter both of money and latency.
Back to the example above: I am a multinational organization (non-ISP).
I have offices all over the world including in New York and Hong Kong.
Imagine the case of a customer of ISP A that is in HK and that wants to
access my HK site. Regardless of the fact that I have different ASes or
not, if I don't announce the HK block longer than my global block, this
is doubly bad because a) the traffic from ISP A's customer in HK goes
all the way to NY on ISP A's backbone and comes back on my internal
network; very bad for latency; b) I also have to carry the traffic back
on my own network, which costs money. Conclusion: the only traffic one
wants to transport on the internal network is internal traffic.

Another topic:
In New York, I buy transit from ISP A and ISP B. In Hong Kong, I buy
transit from ISP C. I want to announce the specifics of the HK block in
both places (for redundancy; if ISP C in HK tanks but my internal
network and links are still up I can do the scenic routing mentioned
above; not good but okay as a backup). If announce the HK block with two
different ASes, I have an inconsistent AS issues (same block sourced by
different ASes).

How do you address this (in IPv4 for a start)?

As far as I know the only available way today is to announce longer
(specific) prefixes with the same AS, prepending it differently for
different blocks at different locations. What am I missing?


> As to GLB, you are not making sense to me.

Maybe by GLB we don't speak of the same thing. I'm not talking about
akamai-like things that trick DNS in one way or the other and do some
custom RTT measuring over UDP from their different hosting farms.

Keep in mind where this started: it would be easier to aggregate IPv6
than it is to aggregate v4. WRT what I wrote above, explain me why.


> [Teredo used as NAT traversal]
> I'm not convinced that is entirely true... I'm sure they could
> have tunneled it all across port 80 (Micr0$0ft is getting very
> good at hiding the entire IP stack inside HTTP(s), and it's an
> increasingly disturbing trend).

I hear your point, but in this case it is.


> [multi-address]
> But, that appeared to be what people were saying was the
> solution for V6 multihoming.

The same brilliant minds that never configured a router in their entire
life, that say that IPv6 renumbering is easy (see below) and that
designed IPv6 never thinking of it as a product that needed to be
deployed in the real world, ignoring basic market realities and the fact
that some pieces of it like multihoming are still missing.


> I'm just trying to figure out what it takes for V6 to have a
> reasonable (the router can parse it and route packets) routing
> table _AND_ allow reasonable multihoming (at least as good as
> what is achievable today).

Nothing is going to be as good as what we have today. MHAP does solve
the reasonable routing table, but at the cost of some added complexity.
No free lunch. One of the things that could have made MHAP worth the
trouble is that it provided not only a solution at the routing table
size but also other perks such as survivability of open sessions in any
failure mode, something that BGP is far from delivering.


> I took the multi-address position from someones paper on "how to
> do it" and didn't develop it myself. I have no religion either
> way.  If there is a single-address way to do it, I'm all for that.
> What is it?

Currently there is none; MHAP would have been the closest I could think
of. The problem of the multi-address solution is not that it's bad; it's
not. It's OK for certain types of setups such as home/soho, but not for
large setups. Early on the ipv6mh days we quickly came to the conclusion
that "THE" IPv6 multihoming solution did not exist; an assemblage of
different collaborative but distinct solutions targeted at different
multihoming needs was the best we hoped for.


> Renumbering a large network is painful in V4.  V6 was supposed
> to have pretty much fixed that.

Absolutely not. Given the current network management practices and
tools, renumbering an IPv6 network is _not_ significantly easier than an
IPv4 network.

> If it didn't, V6 needs more development work until that is fixed.
> Renumbering is a common occurrence for a variety of reasons and
> we should develop tools to make it not painful.

I agree, but IPv6 by itself is not one of these tools. The myth of IPv6
easy renumbering comes from two things: a) stateless autoconfig, which
was nice before we had DHCP, and easy support for multiple addresses per
interface, none of which are any kind of a breakthrough today. If you
have time, read:
http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-
01.txt


> However, in my opinion, multihoming in the traditional sense of the
> word, a single AS attached to more than one upstream transit AS, is
> the harder of the problems to solve, and, it is not clear to me how
> this works in V6.

It does not, because today one can't obtain portable address space that
could be announced to multiple transit ASes and announcing a PA block
you got from one upstream to another upstream does not register.


> This doesn't bode well for IPv6 being adopted any time soon. It
> sounds like there are still many real world operational problems
> that are left as an exercise to the implementer.

Indeed.

Michel.