Hi, > On 3 Mar 2021, at 12:05, Pascal Thubert (pthubert) > <[email protected]> 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 <[email protected]> a écrit : >> >> >> >>> On 1 Mar 2021, at 20:08, Brian E Carpenter <[email protected] >>> <mailto:[email protected]>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > 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
