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?
The protocol specifications of A+P are all standards track. RFC7596, RFC7597, RFC7599. >> 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. For the public IPv4 Internet it is. (Sure there is some support for ICMP as well). >> 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. There’s plenty of room for architectural purity in IPv6. Unfortunately there isn’t that luxury in IPv4 any more. Ole _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
