On 2018-08-02 08:38, Ole Troan wrote:
> Joe,
>
>> I am not ignoring them; I'm claiming that they all have the same inherent
>> deployment and implementation limitations.
>>
>> Just because operators/vendors "want" to do otherwise does not make it
>> possible.
>
> There was IETF consensus behind those documents (A+P).
You mean the *experimental* RFCs that describe an approach that doesn't
update RFC791? (i.e., RFC6364?) Or something else?
> In the _new_ IPv4 Internet architecture the IPv4 header looks like this:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |. 0x45 |Type of Service| Total Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Identification |Flags| Fragment Offset |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Time to Live | 6|17 | Header Checksum |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Source Address |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Destination Address |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Source Port | Destination Port |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> If the the ascii art comes through.
A+P didn't update 791. There is no *new* IP header.
The diagram above is a combination of IP - without options, notably -
and only two specific transports. It isn't an IPsec'd packet, a tunneled
packet, or any other transport. The Internet is not merely TCP and UDP
over IP with no options.
> In contrast to NAT the address and port fields are not rewritten. Only used
> for forwarding.
And there may be limits to where that kind of approach can be deployed.
The jury is still out - this is experimental.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
