Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

[Brian E Carpenter <[e-mail]>]

On 06-Mar-19 05:42, Tom Herbert wrote:
> Hi Brian,
> 
> On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> Hi,
>>
> Hi Brian,
> 
> Thanks for the comments!
> 
>> This is an interesting draft, but I must say I have serious doubts about
>> the IETF working on any significant update to IPv4 at the IP header level,
>> or of any such updates ever making it into the operational network.
>>
> 
> I understand the concern. It's probably true that extension headers in
> IPv4 wouldn't be very usable in today's Internet. Undoubtedly, many
> middleboxes would block them. But that's not because middleboxes are
> concerned about a threat of extension headers in IPv4, it's more
> because some middleboxes drop packets with any protocols they don't
> understand (pretty much leaving only TCP and UDP as being usable
> protocols on the Internet). There are some potential mitigations to be
> pointed out:
> 
> - 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.
> - 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.
> - UDP encapsulation of extension headers could serve to make extension
> headers transparent to middleboxes.
> - It is conceivable to only allow extension headers in UDP
> encapsulation thereby eliminating the problem of making a core update
> to IPv4. IPv4 extension headers would be defined as part of an
> encapsulation protocol.
> - IPv4 extension headers could be another use case for limited domains.
> 
>> On the other hand, I think the idea of a UDP encapsulation of extension
>> headers is very interesting. I'm not sure I understand all the implications
>> yet, and I'm not sure why the format can't be defined simply by a normative
>> reference to RFC8200. The idea of having a duplicate format definition
>> is a bit scary.
> 
> Some implications are described in the document. When encapsulating
> transport packets within UDP the IP header for the encapsulated
> transport header needs to be deterministic, how to deal with NAT and
> encapsulated transport checksum needs a solution. Intermediate nodes
> parsing HBH embedded options is tricky since that requires them to
> inspect UDP payloads and potential modify the payload. For that, a
> magic number is used to minimize the possibility of misinterpretation
> of UDP payload type. If you think of other implications please bring
> them up.
> 
> I'm not sure what the comment on duplicate format definition refers
> to. Perhaps this is about the the description of extension headers for
> IPv4 in the draft?

Yes. I'd rather see them defined as IPv6 extension headers patched for
IPv4, with no duplication of other parts of the definitions. Otherwise
there'll be a risk of them drifting apart.

   Brian    
> 
> Thanks,
> Tom
> 
> 
> 
> 
>>
>> Regards
>>    Brian Carpenter
>>
>> On 28-Feb-19 09:19, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>         Title           : IPv4 Extension Headers and UDP Encapsulated Extension Headers
>>>         Author          : Tom Herbert
>>>       Filename        : draft-herbert-ipv4-udpencap-eh-00.txt
>>>       Pages           : 27
>>>       Date            : 2019-02-27
>>>
>>> Abstract:
>>>    This specification defines extension headers for IPv4 and a method to
>>>    encapsulate extension headers in UDP to facilitate transmission over
>>>    the Internet. The goal is to provide a uniform and feasible method of
>>>    extensibility that is shared between IPv4 and IPv6.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
>>> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>