Hi Toerless,
On 02-Mar-21 04:33, Toerless Eckert wrote:
> It is somewhat ironic to see how it was IP and IPv6 that where the protocols
> that where
> successfully enhanced with additional adress semantics not considered when
> they where designed
> (ok, at last IPv4, but arguably also in a more subtle fashion IPv6). Even
> though as Stewart
> points out, CLNP would be more easily able to absorb additional semantics
> because of its
> flexible address length. But of course new semantics are looking for the best
> model to see
> actual deployments, and that best happens with protocols already most widely
> deployed.
>
> Which at the time IP Multicast was designed was obviously IPv4 (at least in
> the USA where it
> originated), not CLNP.
>
> So now we're stuck that adopting newer semantics like BIER or ICN natively
> into IPv6 is
> primarily not possible because of IPv6 fixed address length. Instead, BIER
> had to do its
> own second network hop-by-ho forwarding protocol/header duplicating all of
> IPv6 as needed,
> just to have longer addresses, and ICN (hICN) proposing which in by book is
> really an
> overlay solution to leave IPv6 pretty much untouched.
>
> I really don't understand why the IPv6 world has not understood how the most
> easy way
> to allow for the applicability of IPv6 to grow (especially beyond "just more
> addresses thn IPv4")
> would be to come up with a backward compatible encap on the wire that would
> support additional
> address lengths.
There is work on supporting shorter address lengths in limited domains where
that is sufficient. I don't think we have a viable use case yet for longer
addresses, although we do have a need for 3GPP operators to support prefixes
shorter than /64, but that's a deployment issue, not a standards issue.
(BIER doesn't strike me as such a use case; an overlay is the natural solution
and it's roughly what Rick Boivie and others proposed in XCAST 20 years ago, as
eventually recorded in RFC5058. I'm fairly uninformed about ICN but again it
seems to me that an overlay is the natural solution and blending it into the
network layer would be spaghetti engineering.)
It would take but a minute to design a longer-address mechanism for IPv6,
although I don't have space to include it in the margin of this email**. But it
would take many years for it to be widely implemented and deployed, during
which time the Internet would be opaque to such addresses.
> We've already seen with SRv6 how more flexible use of addresses can help
> solutions.
Have we really seen that? How many sites are running production traffic using
SRv6? In any case, 128 bits seem to be largely sufficient for SRv6 purposes,
since the semantics are local.
Brian
** Basically, use a prefix such as fb00::/8 to indicate an extended address.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
