Re: IPv4 EH proposal

[Bob Hinden <[e-mail]>]

Tom, Lee,

Please take this discussion elsewhere.  It’s out of scope for the IPv6 list.

Bob


> On Sep 7, 2019, at 9:13 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Sat, Sep 7, 2019 at 8:02 AM Lee Howard <[e-mail]> wrote:
>> 
>> IPv4 is dying. Let it go gracefully.
>> 
> Hi Lee,
> 
> IPv4 has been "dying" for thirty years. I'd call that a slow death! :-)
> 
>> I'm completely opposed to any extensions to the IPv4 specification. By the time the feature set is code complpete, QA'd, and ready for general release, 80% of the world will be using IPv6.
>> 
>> Specific to this case, I have a very hard time understanding the business/engineering case where it would be optimal to implement these extensions rather than deploy IPv6, where they already exist.
> 
> The fact is that there are still many deployments of IPv4 and they
> need to be maintained. We can't force users to switch to IPv6 in any
> timeframe of our choosing and neither is it responsible to abandon
> them. Regardless of what IETF says, vendors will still support their
> customers that choose to stay on IPv4. A good example of necessary
> support is IOAM. IOAM is useful, but not just for IPv6 it would also
> be useful in an IPv4 network. So the IPPM group, which is specifying
> IOAM, is working on a way to add IOAM information into IPv4.
> 
> The idea of IOAM is that intermediate nodes in a path add their
> information to packets in flight, and other nodes consume the
> information. Sounds familiar? This sort of thing is exactly what
> Hop-by-Hop Options are designed to do. But HBH options are currently
> unavailable in IPv4 and there really is no defined and robust
> mechanism in IPv4 that provides the functionality. IPv4 options are
> limited and long considered dead, proposals to put data inside UDP
> encapsulations that intermediate nodes consume or set are problematic.
> The one technique that *might* work is a new GRE Ethertype that does
> nothing more than carry an IOAM header and a next header-- something
> like IP-GRE-IOAM-IP-... Effectively, this is adding extension headers
> to GRE that are identified by an EtherType as opposed to an IP
> protocol number. IMO, this is an abysmal hack! But, it's conceivable
> it could be made to work with enough effort. That also raises the
> spectre of another problem. If the GRE hack works for IPv4 then it
> works IPv6 as well, so a properly lazy protocol developer may use the
> GRE method in IPv6 as well to save development and support costs. So
> even though there is a right solution for IPv6, the wrong solution
> might be used for expediency. In other words, this could be another
> case of people doing things in IPv6 like they did in IPv4 instead of
> leveraging the capabilities of IPv6-- thereby undermining the IPv6
> effort.
> 
> So the idea of IPv4 extension headers is to bring something useful
> from IPv6 into IPv4 for once. In this way IOAM, for instance, can use
> the same and correct solution across both protocols. Also, since the
> protocol number space is the same for IPv4 and IPv6, support for
> extension headers in IPv4 does not change the core IPv4 specification,
> it is enabling use of new IP protocol numbers (something pointed out
> by Brian Trammel). It should also be noted that IPv4 already supports
> AH and ESP so there is already precedent for IPv4 carrying extension
> headers.
> 
> Tom
> 
>> 
>> Lee
>> 
>> On 9/7/19 7:32 AM, Robert Raszuk wrote:
>> 
>> /* Adjusting the subject to reflect the topic */
>> 
>> Ok ... I looked at the new wave of mails in wrong order :)
>> 
>> I like this proposal:
>> 
>> https://tools.ietf.org/html/draft-herbert-ipv4-eh-01
>> 
>> And have absolutely nothing against progressing it further - it looks on the surface to be more efficient then sr-mpls over IP - but how many bits are we saving needs to be calculated to state if cost of introducing new encoding justifies the additional control plane, protocol and platform efforts
>> 
>> In fact if we would get to the consensus of using SRH with SID & BSID to be of fixed 20 bits it can reuse a lot of mechanism build for sr-mpls in any commercial router.
>> 
>> It is just a bit amazing that insertion of EHs into IPv4 would be less problematic that in the case of IPv6 :) Maybe due to allowed fragmentation.
>> 
>> As to the host dropping packets due to unknown protocol - let's observe that SR domain would clean such EH before passing packets further.
>> 
>> Many thx,
>> R.
>> 
>> 
>> 
>> On Sat, Sep 7, 2019 at 1:14 PM Mark Smith <[e-mail]> wrote:
>>> 
>>> On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <[e-mail]> wrote:
>>>> 
>>>>> It's tempting to write up SR over IPv4
>>>> 
>>>> You don't have to write anything ... it is already written and looks like moving fwd :)
>>>> 
>>>> https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07
>>>> 
>>> 
>>> That's tunnelling MPLS over SR over IPv4. I'm talking about native SR
>>> over IPv4 e.g. "SRv4".
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------