/127 between routers?
Jim Burwell
jimb at jsbc.cc
Sun Jan 10 02:25:01 CET 2010
On 1/8/2010 06:45, sthaug at nethelp.no wrote:
>> In summary, this means that IP stack implementations can't rely on a
>> fixed /64 boundary because future standards may come up with new
>> address ranges with semantics that require a non-/64 subnet prefix.
>> So stack implementations should be coded in a way that supports
>> non-/64 prefixes to avoid major rewrites and problems in the future.
>>
>> But anything using addresses from the existing ranges may well assume
>> a /64 prefix in full compliance with the standards.
>>
> Anything assuming only /64 prefixes in the existing ranges would most
> likely fail spectacularly given the number non /64 prefixes in use.
>
> For instance, we number our router loopbacks with /128 prefixes from
> our global /32. Similarly, our links use /124 prefixes. We have no
> intention of changing these to use /64 only.
>
One also wonders if we're making bad assumptions that non-/64s would not
be supported by vendors at all, or in the hardware 'fast path'. Seeing
that similar "l3 switching" is already done in ASICs under IPv4, would
it really add cost or R&D time to basically extend this hardware to work
on 128 bits addresses? I know that in the world of hardware costs,
pennies matter, but it seems some are assuming that routing beyond /64
would add some sort of significant cost or complexity to the ASICs, but
would it really? Especially beyond what they already have to do for /64s.
More information about the ipv6-ops
mailing list