On 03-Mar-21 01:32, Stewart Bryant wrote:
>
>
>> 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.
Short answer: that's why the Internet would be opaque to it for many years.
Longer answer: change every router in the universe (exactly what we did to
achieve the universal deployment of IPv6). At that point, changing the
ethertype/IP version is really not that different than demultiplexing packets
by looking at the first byte of the source address.
But I am not seriously advocating any of this. If I'd believed this was a
viable approach, I would have advocated one of the IPng proposals that extended
IPv4 addressing in that way.
Brian
> 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
