Re: [RAM] Different approaches for different protocols

Excerpts from RJ Atkinson on Wed, Dec 19, 2007 09:59:01AM -0500:
> 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've only seen that idea in miscellaneous speculation.  I don't think
anyone seriously believes we will be able to avoid deploying IPv6.

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

Yes, the "split up the address" set of proposed solutions assume IPv6.

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

To start with we need to evaluate whether an 8+8-style approach is
better than an map&encap approach *at all*, regardless of address
family.  If it is -- which is not clear by any means -- then that will
be the time to consider multiple routing modes.

However, in that case, if production IPv6 routing gets deployed, it
might be just as reasonable to let IPv4 routing consolidate into a
more PA-style mode and not bother doing anything new for it.

swb

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