[RAM] Different approaches for different protocols

[RJ Atkinson <rja at extremenetworks.com>]

There seem to be one or two assumptions implicit in most of
the notes I see archived here and elsewhere on the R&A topic.

	A) We only really need to worry about a solution that
	works for the currently deployed IPv4 network, since
	that is the only network segment that is in near-term
	danger of hitting IDR scaling limits.

I think the above assumption would be incorrect, since IPv6
has the same architectural limitations as IPv4.  Both use
the same BGP-based methods for site-multihoming, which is
the main driver of RIB/FIB entropy at present according to
various papers in the published literature.

	B) We must use the same solution for both IPv4 and IPv6,
	since it is the same fundamental problem.

I think that assumption is also incorrect, since IPv6 does
have many more bits to work with than IPv4.  Purely as an
example, a solution that is part of the 8+8 family is quite
straight-forward to implement/deploy with IPv6 because the
IPv6 address already is conceptually split into two separate
Routing Prefix and Interface ID components.  However, for
IPv4, an 8+8-like solution is more challenging.  One might
use the existing IPv4 "address" as a locator/routing prefix
and then add separate Identifiers as an IPv4 option (workable
in theory, but not in reality because routers would roll over
and whimper like a puppy when trying to send every IPv4 packet
via slow-path CPU forwarding).

So I would suggest that folks think about IPv4 and IPv6 solution
approaches separately.  For example, while one might want one of
the existing proposal for IPv4 (partly for expediency and partly
because IPv4 has more constraints), one might well want a different
more architecturally fundamental change for IPv6 (partly because
the protocol is more flexible due to extra bits in the header
and partly because we have more time to study, prototype, and
design a more elegant solution).

Ran


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram