Subject: The way we already add per-hop information to IP packets (Re: draft-li-6man-ipv6-sfc-ifit-00, and the general problem it raises)

From: Mark Smith <[email-masked]>
Date: Mon, 8 Apr 2019 11:58:47 +1000

Hi Brian,

On Sun, 7 Apr 2019 at 13:10, Brian E Carpenter
<[email-masked]> wrote:
> Hi,

<snip>

> Indeed, we are in the process of creating a big mess and I think 6man
> needs to take this problem very seriously. From nobody taking much notice
> of IPv6 extensibility, we now have lots of people hacking on the topic
> and this needs coordination and consensus.
>
> I won't comment on your specific proposals, because I think the most
> urgent job is to get consensus on the problem area and how to tackle it.
>

I think we already have a proven model of how to add new information
to an existing IPv6 packet, that may or will change at each hop.

It's Link-layer encapsulation.

IPv6-in-IPv4 or IPv6-in-IPv6, from the perspective of the inner IPv6
packet, is treating IPv4 or IPv6 as a link layer. RFC2473, "Generic
Packet Tunneling in IPv6 Specification" is a link-layer specification.

So if IOAM or SR (or anything else) wishes to add new information to
an existing IPv6 packet, that may change at each hop of that IPv6
packet, then it should follow the existing and proven link-layer
encapsulation model to do so. it.

SR over MPLS already does by encoding the SR/SID information in MPLS labels.

Encapsulation is as old as the postal and courier system for our
letters, packages and packets*.

The alternative proposal to adding information to existing IPv6
packets is to split them apart and insert it. Would we accept the
postal or courier system doing the same to our letters, packages or
packets to add routing or other postal/courier information in transit?

(I'd guess in most if not all countries "tampering with mail" is
prohibited by law, and the penalties can be severe - in Australia it
is a criminal office with a jail term of 2 to 5 years. That's how our
letter, package and packet integrity and privacy has been protected.)

Regards,
Mark.

*A letter box in front of a house built around the 1940s/1950s that
accepts packets -

https://photos.app.goo.gl/Naj2XZ6GPCuEAuWFA

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 Apr 2019 14:47:10 -0700

Great. So let's do the math.

Imagine, if you will, that there are 30 hops between A and B, each hop needs to add one byte, and this rule holds. Note that an encapsulation requires at minimum 40 bytes (an IPv6 header), and may require more (Oh, did it need a security header as well, or a destination option, or something else?). How many bytes were added to add 30 bytes?

First, it's not link-layer. It's IP layer. The relevant link layer protocols may or may not support the information you want to add, and if they do, may not create an extended link layer region where you want it. Consider, if you like, what happens in a switched Ethernet. What header do you put the additional byte in? 30*14=what?

I understand the issues with adding a byte in transit; you may recall that I wrote an I-D related to it at one point. But this level of blithe intransigence seems a little over the top. It's not an answer, it's "shut up and go away; I don't want to hear about it."

> On Apr 7, 2019, at 6:58 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi Brian,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Apr 2019 10:25:21 +0200

> I understand the issues with adding a byte in transit; you may recall that I wrote an I-D related to it at one point. But this level of blithe intransigence seems a little over the top. It's not an answer, it's "shut up and go away; I don't want to hear about it.”

I expect how this is used is like RFC791, SSRR option. The source of the packet leaves scratch space in the packet. Encap would only happen once per “domain”.

Cheers,
Ole