On Mon, Mar 1, 2021 at 2:08 PM Brian E Carpenter < [email protected]> wrote:
> 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. > > Well said :) Behcet > > 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 >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
