Thanks, Stewart, inline..
On Tue, Mar 02, 2021 at 01:53:12PM +0000, Stewart Bryant wrote:
> I don???t think there is a simple backwards compatible approach, but we can
> probably do more than we do today.
>
> Backwards compatible means that you could put your new packet into a IPv6
> parser and it would correctly forward the packet as if nothing had changed.
Lets say for the sake of argument, IPv6 multicast routing would have been added
after IPv6 (unicast)
was first specified, as it actually was in IPv4 (but nobody wants to hear IPv4
stories now *sob* ;-).
Adding IPv6 multicast would then also not have been a backward compatible
extension in your definition. As would likely be any interesting new semantic
to be added - whether
or not that semantic requires packet header changes or not. So i think your
definition of
backward compatible is too constraining:
In my definition, IPv6 multicast was backward at the system level because it
allowed/allows IPv6
unicast to continue to exist and evolve as if IPv6 multicast didn't exist. With
the only
limitation that some address planning was/is needed to be able to carve out
unused address
space for new semantics.
With this definition of backward compatibility i can equally introduce in a
backward
compatible fashion new addresses longer or shorter than 128 bit through
arbitrary packet
header enhancemeents, because all i need is to observe that the format on the
wire of
consenting subnet adjacent routers is nobodies business but theirs - as long as
they
manage to stay backward compatible in my definition. And when we utilize
additional
packet header fields or different addrss lengths, we would not even have to
carve
out more from existing IPv6 address space like we logically had to do for IP
multicast
and avoid further overloading of this address space (as Tony i think observed
to be a problem).
That all being said: Of course, we can and should try to promote more
fundamental
enhancements to the definition of forwarding machineries to allow future
extensions
of semantics to be possible in-line with your definition of backward
compatibility, but
that i think a lot more ambitious.
Cheers
Torless
> You could I suppose put a well known IPv6 address in the IPv6 header and put
> the real address in an extension header, perhaps including the pointer to the
> address in the suffix of the IPv6 address to make finding the EH much faster,
> but I am not sure that is backwards compatible.
>
> I suppose it might be able to do a bit better if the address in the IPv6 DA
> was the DA of the egress router and old routers did best effort to the egress
> and newer routers knew to take a look at the extension header for more detail.
>
> I think that it is worth thinking about how we could do better than we do
> today, but I think we need to be careful with the term backwards compatible.
>
> - Stewart
>
>
>
>
--
---
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
