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

Hi,

> On 3 Mar 2021, at 12:05, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hello Stewart, Brian and Toerless:
> 
> Interestingly RFC 8138 took one step in that direction. Yes you’re going to need a new Ethertype but it’s still IPv6 I.

IMHO, from an architectural point of view I would argue that it is a different L3 protocol: different header; different forwarding machinery;

The fact that has been designed to be « compatible » with IPv6, where a simple method exists to translate one in the other, basically having a one-to-one mapping,  is a different thing. 

Yet, I would also add that the real objective of the discussion is whether or not it exists a sufficiently general mechanism that enables the same feature (as for RFC 8138)  among different limited domains.

If it exists, what is the general addressing « model » (for lack of a better term) that would accommodate such a requirement or allow to create such a general solution?

Ciao

L.

> That is is expressed as a compression not a modification of IPv6.
> 
>  In the compressed form the header starts with the next hops, the destination and SRH being indiscriminated, the destination is just the first of the list. The size is variable but each hop is at most 128 bits. Because the SRH could encode SRv6 you can already go a long way with this.
> 
> If that can help you do what you want, I m happy to explain more...
> 
> Keep safe.
> 
> Pascal
> 
>> Le 2 mars 2021 à 13:33, Stewart Bryant <stewart.bryant@gmail.com> a écrit :
>> 
>>  
>> 
>>> On 1 Mar 2021, at 20:08, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> ** Basically, use a prefix such as fb00::/8 to indicate an extended address.
>> 
>> Hi Brian
>> 
>> Basically I think that this fails the backwards compatibility text.
>> 
>> It is perfectly legitimate to write an IPv6 forwarder as follows:
>> 
>> If MACaddress == me and MACtype == IPv6 pass packet to IPv6 forwarder
>> 
>> In IPv6 forwarder:
>> 
>> If version == IPv6 and Hop Limit not exceeded send bytes 24 to 39 to address lookup engine
>> 
>> Wait for address result and forward packet accordingly
>> 
>> Except that this forwarder would have sent a bunch of random junk to the ALE consisting of some of the SA and maybe some of the DA depending on their sizes.
>> 
>> So to stop an old and legitimately designed parser being fooled you really have to use a new MAC type and a new version and as soon as you do that you might as well design the packet optimally for the job at hand.
>> 
>> If the IPv6 designers had followed the strategy of both the Ethernet designers and the ISO8473 designers and put DA before SA then the elegant approach that you and others have  proposed at various times would have worked nicely.
>> 
>> Best regards
>> 
>> Stewart
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area