On Fri, Mar 8, 2019 at 2:02 AM Fernando Gont <[email protected]> wrote: > > HIi, Tom, > > On 5/3/19 13:42, Tom Herbert wrote: > > Hi Brian, > > > > On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter > > <[email protected]> wrote: > >> > >> Hi, > >> > > Hi Brian, > > > [... > > - IPv4 already supports at least two extension headers, namely ESP and > > AH. They might not be called extension headers, but they have the same > > format and function as IPv6 cognates. > > - There's no concept of HBH options in IPv4 as needing to be processed > > by every node in the path, so the relaxed processing requirement of > > RFC8200 can be set from the start without legacy issues. > > Aren't all IPv4 HBH optons, essentially?
Maybe they could be considered that in that they can be processed in the network. However, they don't have the bits in the type field that indicate modifiable options or what to do with an unknown option. > > > > - This doesn't actually change IP header, it is just enabling new > > values in the protocol field. In a host implementation this is very > > straightforward and in some ways it's a simplification to to be more > > like IPv6. > > Haven't checked the I-D yet. Quick question: do you expect NATs parse > past this EHs to be able to do NAPT as they do nowadays? > No, I wouldn't expect that. To get IPv4 extension headers through a NAT,stateful firewall, etc. encapsulation in UDP can be done. Native IPv4 extension headers would probably be most useful in a limited domain. Tom > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
