[ppml] IPv6 flawed?
owen at delong.com
Mon Sep 3 03:14:22 EDT 2007
On Sep 2, 2007, at 1:21 PM, Iljitsch van Beijnum wrote:
> On 2-sep-2007, at 6:37, Paul Vixie wrote:
>>> - It never delivered initial promises, such as aggregation (the "8K
>>> DFZ"). In their great wisdom, the IETF pushed the protocol out
>>> with the
>>> promise that they will deliver the missing features (such as
>>> and effortless renumbering) later.
> IETF is still working... And it's not like adopting PI in the mean
> time helps.
I strongly disagree. Adopting PI in the mean time can serve as very
useful input to express to IETF that they _MUST_ solve the routing
problem in a scalable way. And ID-Locator split is long overdue.
> That's only half a solution, the way it was written down 10 years ago
> doesn't do anything useful. If you fix the problems, you end up with
> something like shim6.
Shim6 is far too complicated to actually see reliable implementation
in the average enterprise and it does nothing to help with easy
> The problem isn't that we don't know how to fix the problems: we do,
> and often the protocols exist. It's living with the tradeoffs that we
> as a community have a problem with. We want small routing tables, but
> we also want PI. We want stable addresses for applications so the
> network must figure out reachability, but we also want to connect to
> a remote host without delay. We want security and encryption, but not
> a PKI.
We don't want small routing tables. We want routing tables that fit
in existing hardware and a churn-rate which can be handled by the
hardware. I don't think anyone actually cares if the routing table
is 10,000, 150,000, or 230,000 routes. Sure, they worry if it's
500,000 routes or more, but, wanting to avoid an excruciatingly
large routing table is different from wanting a small one.
PI is a necessity. CIDR and PA were horrible hacks put in
place as a band-aid until IPv6 could be engineered to truly
solve the routing problem in a scalable fashion. I have no
idea why an ID/Locator split was not made a built-in part
of IPv6, but, I believe it can be added without reworking the
protocol, so, there is still a way forward.
> IPv6 has some innovation on the link, such as autoconfiguration,
> which many people don't like, by the way, but other than that, it's
> just IP that we know and love with larger addresses. So it has all
> the downsides of IPv4, only now we get to build a bigger network so
> the downsides are all the more troublesome.
IPv6 has worse downsides than IPv4. I can see a few rare instances
where autoconfiguraiton could be considered a useful feature, but,
even in those cases, I don't see where it is significantly better than
DHCPv4. Hopefully, eventually, DHCPv6 will be full featured, too,
and, stateless autoconf will take it's rightful place next to RARP as
something which works but is rarely used any more.
More information about the ARIN-PPML