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

[Jiayihao <[e-mail]>]

Hi Brian, toerless,

A longer-address mechanism is not intended to cover scenarios of IPv6. As for global reachability, IPv6 is an on-going direction we are increasingly developing. 
I think the discussion is attribute to the size of the Address. Given that IPv6 is presented as uni-size, it is possible that there might be scenarios that prefer the size other than the an unique bit length. For these scenarios, certain cost will emerges if solutions are all built on an uni-size space.

So the point is, we enjoy the advantage of the uni-size length, but for certain scenarios, we still need to tolerate the cost, or side effect when a function/process must be carried within the uni-size space.

The I-D. (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/) which we draft recently is intended to cover such scenarios and the problems. It covers no solutions to these scenarios, but help us identify the related problems within the uni-size space. Probably it is a good base for discussion.

Thanks,
Yihao

----------
发件人: Brian E Carpenter [mailto:[e-mail]] 
发送时间: 2021年3月2日 4:08
收件人: Toerless Eckert <[e-mail]>; Stewart Bryant <[e-mail]>
抄送: [e-mail]; [e-mail]; int-area <[e-mail]>; Jiayihao <[e-mail]>
主题: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

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.