Re: IPv4 EH proposal

On Sat, Sep 7, 2019 at 8:02 AM Lee Howard <lee@asgard.org> 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 <markzzzsmith@gmail.com> wrote:
>>
>> On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <robert@raszuk.net> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------