[RAM] Different approaches for different protocols

RJ Atkinson <rja@extremenetworks.com> Wed, 19 December 2007 14:59 UTC

Return-path: <ram-bounces@iab.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50O0-0005lQ-VB; Wed, 19 Dec 2007 09:59:04 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Nz-0005jd-70 for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500
Received: from eastrmmtao107.cox.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Ny-0007aD-Pz for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500
Received: from eastrmimpo01.cox.net ([]) by eastrmmtao107.cox.net (InterMail vM. 201-2186-121-102-20070209) with ESMTP id <20071219145901.FMUA8815.eastrmmtao107.cox.net@eastrmimpo01.cox.net> for <ram@iab.org>; Wed, 19 Dec 2007 09:59:01 -0500
Received: from [] ([]) by eastrmimpo01.cox.net with bizsmtp id SeyH1Y0080aEP1Q0000000; Wed, 19 Dec 2007 09:58:17 -0500
Message-Id: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com>
From: RJ Atkinson <rja@extremenetworks.com>
To: ram@iab.org
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 19 Dec 2007 09:59:01 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [RAM] Different approaches for different protocols
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

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).


RAM mailing list