Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

On Mon, Mar 1, 2021 at 2:08 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>