Subject: Next steps on advancing core IPv6 specifications to full Internet standard

From: [email-masked]
Date: Tue, 15 Nov 2016 15:19:45 +0900

The 6MAN working group has been working on advancing the core IPv6
specifications to Internet Standard.  The next steps to achieve this
goal is described here.

We have now finished the edits on the RFC2460bis, RFC1981bis and
RFC4291bis documents. With the agreement in today's working group
session on the header insertion issue for 2460, the working group last
call is now complete.

The chairs have decided to declare consensus on the following text:
(that includes a small amendment proposed in the meeting).

   The insertion of Extension Headers by any node other than the
   source of the packet causes serious problems.  Two examples include
   breaking the integrity checks provided by the Authentication Header
   Integrity [RFC4302], and breaking Path MTU Discovery which can
   result in ICMP error messages being sent to the source of the
   packet that did not insert the header, rather than the node that
   inserted the header.

   One approach to avoid these problems is to encapsulate the packet
   using another IPv6 header and including the additional extension
   header after the first IPv6 header, for example, as defined in
   [RFC2473]

New revisions of RFC2460bis and RFC4291bis will be published shortly,
and the intention is to have the IESG writeup and the advancement done
by November 22th.

We will send the IESG the following letter to request reclassifying
RFC3596 and RFC4443 in-place as Internet Standards.

The goal is for all five of these documents to be Internet Standards.

Attached is the draft letter to the IESG.

Best regards,
Ole and Bob

------------------------

Dear IESG,

The 6MAN working group requests that the IESG initiate the process to
reclassify the following two draft standard RFCs as Internet Standard.

Following the requirements in RFC6410, section 2.2:

(1) There are at least two independent interoperating implementations
     with widespread deployment and successful operational experience.

(2) There are no errata against the specification that would cause a
    new implementation to fail to interoperate with deployed ones.

(3) There are no unused features in the specification that greatly
    increase implementation complexity.

(4) If the technology required to implement the specification
   requires patented or otherwise controlled technology, then the
   set of implementations must demonstrate at least two independent,
   separate and successful uses of the licensing process.

RFC4443 (https://datatracker.ietf.org/doc/rfc4443/)
  (1) Widely implemented:
      https://www.ipv6ready.org/db/index.php/public/?o=4
  (2) 4 errata, none of which would cause new interoperability
      problems.
      RFC4443 is updated by: RFC4884, but the consensus is that this update
      it’s not an update, it is an extension to the protocol.
  (3) There are no unused features.
  (4)  No known IPR.

RFC3595 (https://datatracker.ietf.org/doc/rfc3596/)
  (1) Widely implemented:
      https://www.ipv6ready.org/db/index.php/public/?o=4
  (2) No errata. No updated by.
  (3) There are no unused features.
  (4) No known IPR.

Bringing IPv6 draft standards to full standard has been worked on in
the 6MAN working group for some time. The documents for
reclassification have been reviewed in multiple face to face working
group sessions and on the mailing list, and there is a strong
consensus in the working group to have these documents reclassified as
Internet Standards.

Best regards,
Ole & Bob - on behalf of the 6man Working group

---

From: 神明達哉 <[email-masked]>
Date: Wed, 16 Nov 2016 11:18:27 -0800

>    header after the first IPv6 header, for example, as defined in

Am I correct that an agreement in a f2f session must first be
confirmed in the mailing list and this case is not an exception?

Assuming so, I'd like to say I still have a serious concern with this
text in that it's as "ambiguous" to the extent the original RFC2460
was ambiguous regarding whether the protocol intends (intended) to
allow such extension header insertion.  I'm concerned about this
because such ambiguity can lead to casual violation of the intent (we
know the intent was to not allow it) and casually dismissing the
stated problems and other issues that are not explicitly noted in the
text.  The existence of segment routing implementation for the Linux
kernel (a general purpose operating system) suggests it's not just an
imaginary concern: http://www.segment-routing.org/index.php/SR/SR-IPv6

It's true that no matter how clearly we clarify the intent there is
always someone who violates it, either intentionally or carelessly.
But that doesn't mean we should drop the effort of making it clearer
completely.  IMO it has non-marginal effect to warrant a caution if we
explicitly clarify the original intent (and, ideally, if we also state
an attempt of loosening the intent requires a great care).

If the current "compromise" text comes from the concern that any
clarified intent can be interpreted as an "outright ban" of such
insertion, prohibiting any future update to the restriction, we can
also clarify that's not the intent of the clarification.  I don't
think these cannot coexist.

I didn't attend the wg session (or for that matter I was not in Seoul
in the first place), so I don't know what kind of discussion the
participants had to reach this agreement.  Maybe the points I'm now
making were already covered and rejected, but I should still have the
right to make these points on my own behalf even if I'm a hapless
minority.  Hopefully there are some more who were not in the session
but share this view and we can still revisit the text.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2016 09:02:06 +1300

On 17/11/2016 08:18, 神明達哉 wrote:
...
> was ambiguous...

I think the question of principle here is whether a document with
a known ambguity is qualified to become an Internet Standard.

If this WG can make no more progress on that question (and I have
sympathy with the WG Chairs on that), it becomes a question for
the community and the IESG during IETF Last Call.

As far as I can tell, ambiguity is not mentioned explicitly in
RFC 2026 or RFC 6410.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 17 Nov 2016 05:35:27 +0000

> On 16 Nov 2016, at 20:02, Brian E Carpenter <[email-masked]> wrote:
> 

Presumably that manifests itself when you consider whether implementations are interoperable and have widespread deployment and successful operational experience. 

Tim

---

From: Hemant Singh <[email-masked]>
Date: Thu, 17 Nov 2016 07:46:58 -0500

I agree with Jinmei.  It's not just SR in the Linux kernel.  The Linux user
space also has one implementation that adds/deletes the EH.  See

https://mailarchive.ietf.org/arch/msg/ipv6/sYxrnN45cEu1PyqftDICQ-Yl3Rg

 Inband OAM uses Add/delete of EH in the FD.io implementation which runs in
the Linux user space.    I was told  "Inband OAM especially is not possible
with encapsulation since we want the source and destination to not change."

Why not preserve the original source and destination IPv6 addresses in
another IPv6 option and use encapsulation.

Hemant

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Nov 2016 22:55:04 +0900

Jinmei-san,

> On Nov 17, 2016, at 4:18 AM, 神明達哉 <[email-masked]> wrote:
> 

This is that confirmation.  That why it said “our intention is to have the IESG writeup and the advancement done by November 22th”.  We should have been clearer.

> imaginary concern: http://www.segment-routing.org/index.php/SR/SR-IPv6

We think the clear consensus of the working is to describe the problem.  There was not a consensus to either ban header insertion, or to not say anything.  We have also recommended to the working group that it would be worthwhile to write a new document that covers this topic in detail.  We hope you will contribute to that work.

As Brian Carpenter noted, “ambiguity” is not called out in RFC 2026 or RFC 6410.  The issue has existed since RFC2460 (and RFC1883 before that).  We think the real issue is if this causes an interoperability problem.  There doesn’t seem to be an evidence that there is an interoperability problem.  We think the new text will help by describing the problem.

> but share this view and we can still revisit the text.

It was discussed, you can see it at

  http://ietf97.conf.meetecho.com/index.php/Recordings#tue

A debate similar to the points you raised occurred.  As we noted, the conclusion was to go with the text you are commenting on.

We did show at the session the proposed text you sent on the mailing list, but there was not an agreement to adopt it.

Thanks,
Bob & Ole

---

From: Hemant Singh <[email-masked]>
Date: Thu, 17 Nov 2016 09:22:13 -0500

I have cced to a few SR folks.  Why did the SR implementation in the Linux
kernel go with add/delete EH rather than encapsulation?   Why wasn't
encapsulation used first with SR for the Linux kernel implementation?

Thanks,

Hemant

---

From: Hemant Singh <[email-masked]>
Date: Thu, 17 Nov 2016 10:33:04 -0500

On Thu, Nov 17, 2016 at 8:55 AM, Bob Hinden <[email-masked]> wrote:

>
> There doesn’t seem to be an evidence that there is an interoperability
> problem.
>
>
A SR deployment uses source routers from different vendors.  One vendors
uses "add an EH header" while another uses the encapsulation method to add
the SR info  The intermediate routers have to read the encoded SR
instructions for forwarding.  How is the intermediate node instructed to
decapsulate and read vs. look at an added EH by the source?  Maybe SR deals
with this issue and if so, please let me know which of several SR I-D's
cover the details.

Likewise, Inband OAM has mixed router/switch vendor deployment.  One vendor
uses add/delete EH while another uses encap.  How are all routers/switches
instructed to use which method?

When folks get a chance, could they please also reply to my questions on
Inband OAM and SR in earlier emails from today.   It is useful to the
mailer to articulate what show stopper problem did one encounter that one
could not use encapsulation.   Only once such issues are closed, one can
start the other document that would cover pitfalls of add/delete EH by
intermediate nodes.

Thanks,

Hemant

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Nov 2016 08:45:51 +1100

> As far as I can tell, ambiguity is not mentioned explicitly in

I think people might be assuming that ambiguity is the only cause of people
thinking EH insertion is permitted.

I think there are at least four potential other reasons:

- they've never read the EH section of RFC2460, which is clear about what
and where EHs are allowed and intended to be examined and processed.
(Specifically the second and third paragraphs, after the diagram.)

- they've read the EH section of RFC2460, understood it,  but they've since
forgotten what it said.

- they've read the EH section of RFC2460, understood it, but have chosen it
ignore it.

- they've read the EH section of RFC2460, however haven't fully understood
it properly because English is not their first language.

I would think in this last case it is likely that at least the term
"processed" would be understood, because a version of that word is part of
the acronym CPU.

I'd really like to see it explained how those EH sections if RFC2460 are
ambiguous before I'd be willing to accept that claim.

Regards,
Mark.

>    Brian
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Hemant Singh <[email-masked]>
Date: Thu, 17 Nov 2016 17:41:42 -0500

I never liked the use of "processed" whether one is a native speaker of
English or not.   It's too loose.  I prefer:

1. Inspect EH before forwarding or not.
2. Add/Delete EH before forwarding or not.

Hemant

On Thu, Nov 17, 2016 at 4:45 PM, Mark Smith <[email-masked]> wrote:

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2016 11:43:42 +1300

On 18/11/2016 10:45, Mark Smith wrote:
...
> ambiguous before I'd be willing to accept that claim.

Mark, ambiguity is in the mind of the reader, not the writer. So when
I see people who cite RFC2460 and who believe that it allows header
insertion, and other people (including myself) who believe that it forbids
header insertion, that's an operational proof of ambiguity.

It's all very well to ask "Which word in 'processed' don't you understand?"
but if different people interpret it differently, it's behaving as an
ambiguous word.

IMHO, we're beyond the point where discusion within the WG will achieve
anything. In IETF Last Call, anyone can state their views, and probably will.

Rgds
   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Nov 2016 18:42:28 -0600

> header insertion, that's an operational proof of ambiguity.

I wanted to stay out of this one, but to be honest;

I read the current language in 2460bis-08 as "intermediate nodes SHOULD NOT
insert EH, its RECOMMENDED that you encapsulate."

Where as the original 2460 text, does not explicitly address the issue, but
I don't see how it can be interrupted as allowing an intermediate node to
insert an EH.

What I heard asked for is that 2460bis explicitly address the issue, that
is to make it abundantly obvious that "intermediate nodes MUST NOT insert
EH".

While I agree with this personally, I also agree there doesn't seem to be
consensus for that.

I can not agree with the proposed text, and at this point I would prefer
the original 2460 text, if there isn't a consensus for making it abundantly
obvious that "intermediate nodes MUST NOT insert EH".

Not sure that helps, but I tried.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Hemant Singh <[email-masked]>
Date: Thu, 17 Nov 2016 20:56:03 -0500

I agree with Brian for what he said below.  Let's move the rfc2460bis doc
to the IESG.   I would like to work with implementations later for why they
went with the "add EH by intermediate nodes" rather than encapsulations.

Regards,

Hemant

---

From: Tom Herbert <[email-masked]>
Date: Fri, 18 Nov 2016 17:45:36 +0900

On Thu, Nov 17, 2016 at 11:22 PM, Hemant Singh <[email-masked]> wrote:

> The implementation doesn't distinguish between being a host and being a
router in this case. If the forwarding instructions are to insert a header
then that is what's done. Encapsulation is just an alternate method that
should already be supported and similarly would work for a host or router.
Basically, we are leaving it up to the user rather inserting EH in the
network is reasonable, however a warning about inserting EH based on the
proposed text will be added to the documentation.

Thanks,
Tom

Thanks,

---

From: Hemant Singh <[email-masked]>
Date: Fri, 18 Nov 2016 08:41:30 -0500

Got it - thanks, Tom.

Did you see my other email related to both the implementations for SR and
Inband OAM with mixed nodes?  How do nodes know where to add the OAM data
or parse the SR encoded data if one vendor's node uses add EH while another
vendor's node uses encapsulation?    If both implementations continue to
live, we need means to signal to the network what mode is being used for
certain protocols.   Some means I see are a new DHCPv6 option, a new
option/bit in the IPv6 ND RA, a new next_hdr in the IPv6 header, or use
some bits from the Traffic Class and Flow Label in the IPv6 header.

Thanks,

Hemant

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Nov 2016 11:14:07 -0800

At Thu, 17 Nov 2016 22:55:04 +0900,
Bob Hinden <[email-masked]> wrote:

> As Brian Carpenter noted, “ambiguity” is not called out in RFC 2026
> or RFC 6410.  The issue has existed since RFC2460 (and RFC1883
> before that).  We think the real issue is if this causes an
> interoperability problem.  There doesn’t seem to be an evidence that
> there is an interoperability problem.  We think the new text will
> help by describing the problem.

I don't want to waste everyone's time by just repeating what I said
before (which would possibly be another round of the same discussion),
but this logic ("we don't have to or shouldn't clarify the ambiguity
since there is no evidence that the lack of clarification caused an
interoperability problem") is one major thing I've not
understood/bought throughout this discussion.  With that logic we
could never introduce a MUST NOT when designing a new protocol, since
obviously there's no evidence of an interoperability problem in such
cases.  Also, in the case of this header insertion issue, I suspect
the more likely situation is that the original intent (of not allowing
an intermediate node to insert EHs) was actually pretty clear for most
of us, so there were simply very few attempts to violate it (and when
it was violated it, it was probably quite limited or they were very
careful to control the setup to avoid interoperability problems).  If
that's the case, the question to be asked is not whether there is an
evidence of an interoperability problem but how likely it can cause
such a problem if we allow casual violation of the original intent.
I interpret the consensus of describing the problems as most people
agreed (perhaps reluctantly for some of them) it's quite possible.
And, in that case, I believe we should also clarify the ambiguity that
can make the problems happen.

Anyway, I don't intend to make this thread unnecessarily longer just
for another round of the same discussion, so I'll shut up here.  I'll
basically just see if there are other people who were not in the f2f
session and are willing to revisit the consensus at that time.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Nov 2016 08:25:18 +1300

Hemant,

> some bits from the Traffic Class and Flow Label in the IPv6 header.

There are no spare bits in the Traffic Class or the Flow Label.

(To be precise: ECN has two bits and diffserv has 6 bits. And the flow
label bits are not allowed to have semantics of any kind.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Nov 2016 08:29:10 +1300

On 19/11/2016 08:14, 神明達哉 wrote:
...
> session and are willing to revisit the consensus at that time.

I don't think the WG consensus call was wrong. I do think the WG rough
consensus is wrong. But it's not an IETF consensus, so it's open for challenge
during IETF Last Call.

    Brian

---

From: Hemant Singh <[email-masked]>
Date: Fri, 18 Nov 2016 14:29:12 -0500

Brian,

I totally hear you.   This is why I had given Traffic Class and the Flow
Label as the last option.  My intent was to use such bits of another
purpose in a private network.  I already know of a web-scale operator who
uses the Flow Label for ECMP hashes and ECMP routing.  Recall the 20-bit
hash discussed in v6ops by Google?

Cheers,

Hemant

---

From: Bob Hinden <[email-masked]>
Date: Sat, 19 Nov 2016 12:44:13 +0900

Hi,

After reading the emails since this thread started, we don’t see anything to change the chairs consensus determination.  It still clear that the w.g. has strong views on both sides of this issue, and support for going forward with the problem description text.  Note, this is not our personal view and would have preferred something stronger, but it is our job to help the w.g. reach a consensus and that is sometimes a compromise.

The chairs will clearly document the Extension Header insertion issue in the the writeup to the IESG when the advancement happens.  This will let the IESG better understand the issues when they discuss it.

Thanks,
Bob & Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 21 Nov 2016 09:44:17 -0800

> Rather or not encapsulation is used, the SR EH would be an extension of
the outermost IP header. Intermediate routers would not be concerned with
rather the packet is encapsulated except when they are the terminal point
of the encapsulation (need to decapsulate). So the SR EH is processed the
same by intermediate nodes whether encapsulation is used or not.

> This is inband OAM in an EH or within an encapsulation? If it's in an
extension header then a similar concept would apply, the EH, presumably a
HBH option, would need to be set in the outer IP headers so that it is
processed be intermediate nodes. If an option is writable in then the
encapsulation might need to copy the information to an EH in the original
packet if necessary. If the OAM is part of encapsulation then its operation
would be specified in the encapsulation.

> Note that the suggestion to use encapsulation is not normative, it does
not provide exactly the same behavior as inserting EH would (for instance
ECMP handling would be very different). I think the interaction between EH
and encapsulation needs to specified as part of the encapsulation, for
instance the question of what EHs must be copied from the packet being
encapsulated to the outer packet will need to be addressed.

Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Nov 2016 06:55:35 +1100

I think this discussion about specific details of specific inserted EHs is
irrelevant.

EH encapsulation vs insertion is as fundamental as whether you believe in
the layered computer networking model or not, where information is added or
removed to PDUs at layer boundaries via encapsulation as they go up and
down the layers, and PDUs are left alone when they travel within a layer
between layer senders and receivers.

It also relates to the difference between what End Systems functions are
and what Intermediate Systems functions are.

Inserting into a previously created PDU, at the same layer, doesn't comply
with that model. It never will regardless of the type of EH inserted,
because insertion is not part of that model.

On 22 Nov. 2016 4:44 am, "Tom Herbert" <[email-masked]> wrote:

> Likewise, Inband OAM has mixed router/switch vendor deployment.  One
>> vendor uses add/delete EH while another uses encap.  How are all
>> routers/switches instructed to use which method?
>>

---

From: Hemant Singh <[email-masked]>
Date: Mon, 21 Nov 2016 22:22:21 -0500

Tom,

Please see in-line below against "<hs>".

On Mon, Nov 21, 2016 at 12:44 PM, Tom Herbert <[email-masked]> wrote:

Rather or not encapsulation is used, the SR EH would be an extension of the
> outermost IP header. Intermediate routers would not be concerned with

<hs> Agree.  I thought intermediate nodes in SR could add a new SR info and
then another layer of encapsulation is used.   It turns out, this is not
the case.

>> This is inband OAM in an EH or within an encapsulation?
>

<hs> Inband OAM in an EH.  If encapsulation is used each node in the path
of the packet adds a new IPv6 header followed by a Hop-by-Hop (HBH) EH.
The EH includes OAM data.  Now if encapsulation is not used, each node adds
a its own EH - at least this is how the FD.io Inband was described to me.
Thus all nodes have to be instructed how to add the OAM data using
out-of-band mechanisms such as DHCPv6.

> <hs>Hmm.  ECMP is used when multiple paths exists to a destination.   If
> each node in the packet path uses encapsulation, the new IPv6 header added
> by the node, still has the destination identical to the destination when
> the packet was sourced.  So why should ECMP be impacted whether
> encapsulation is used or not?
>

Thanks,

Hemant

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Nov 2016 10:02:26 +0000

Hi,

On 22 Nov 2016, at 03:22, Hemant Singh <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

<hs> Inband OAM in an EH.  If encapsulation is used each node in the path of the packet adds a new IPv6 header followed by a Hop-by-Hop (HBH) EH.  The EH includes OAM data.  Now if encapsulation is not used, each node adds a its own EH - at least this is how the FD.io<http://FD.io> Inband was described to me.  Thus all nodes have to be instructed how to add the OAM data using out-of-band mechanisms such as DHCPv6.

The thing is, and I raised it in 6man in Seoul, insertion is not described in the SR architecture or the IPv6 Data Plane drafts.

In draft-ietf-spring-segment-routing-10, the specifics of how the SRH is added are not discussed.

Indeed, that draft says the SRH is “installed” in 8.2: "In the general case, an SR IPv6 router accepts and install segments identifiers (in the form of IPv6 addresses)”.  “Install" is pretty vague.

In draft-ietf-6man-segment-routing-header-02 there is no mention of insertion. In 2.2 it says:

" While the source routing model defined in [RFC2460<https://tools.ietf.org/html/rfc2460>] doesn't mandate

   which node is allowed to insert (or modify) the SRH, it is assumed in
   this document that the SRH is inserted in the packet by its source.
   For example:

   o  At the node originating the packet (host, server).

   o  At the ingress node of an SR domain where the ingress node
      receives an IPv6 packet and encapsulates it into an outer IPv6
      header followed by a Segment Routing header.”

The “For example” of course allows wiggle room, and this text also seems to imply that the authors believe RFC2460 allows insertion on path.   Further, Hemant’s comment says that at least one implementation of IPv6 SR does insertion on path, without it being explicitly defined in a WG draft, yet alone an RFC.

Also, Section 5 (Security Considerations) of draft-ietf-6man-segment-routing-header-02 doesn’t discuss the downsides of header insertion that have been documented in 2460-bis.

So there’s a lot of vagueness about the whole SRH “insertion” issue, partly in the spring WG, partly in 6man, and implementation(s) doing things that are not (as yet, or perhaps never will be?) documented in the IETF.

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Nov 2016 22:37:37 +1100

On 22 November 2016 at 21:02, Tim Chown <[email-masked]> wrote:
> Hi,
>
> On 22 Nov 2016, at 03:22, Hemant Singh <[email-masked]> wrote:
>
> <snip>
>
>
> So there’s a lot of vagueness about the whole SRH “insertion” issue, partly
> in the spring WG, partly in 6man, and implementation(s) doing things that
> are not (as yet, or perhaps never will be?) documented in the IETF.
>

This draft is well and truly doing it, despite the title.

"Encapsulations for In-situ OAM Data"
https://tools.ietf.org/html/draft-brockners-inband-oam-transport-02

"3.1.2.  Procedure at the Ingress Edge to Insert the In-situ
               OAM Header"

Imagine if one of those inserted EHs wasn't stripped at the edge of
the OAM domain, because of an implementation bug or configuration
error.

These OAM EH inserted packets arrive at your network and breaks the
application you're providing to a paying customer somewhere across the
Internet. This paying customer is the one that constructed and
originated the packet, and is identified by the source address.

So you contact the customer identified by the source address asking
them why are they inserting and sending OAM EHs to you. The say 'no,
we are not, and send a packet capture to prove it.

Since you're in Australia, and they're in Europe (or the US), there
are now many different networks between them and you. How do you work
out who is inserting these EHs and then not removing them?

You spend days and weeks contacting *all* the ASNs between you and
your customer (10 perhaps?), asking them if they're (a) inserting
these EHs, (b) if they are, can they determine if their equipment is
configured to remove them, and if it is (c) tell them they've got a
bug and need to contact their vendor. While they're waiting for their
vendor to fix the bug, they're probably not going to be very keen to
switch off this wonderful feature that is working fine for them ...
because they' actually don't suffer from any consequences of the EHs
they've added but not removed.

So you call up your customer, after they've suffered from a number of
weeks of lost service from you. "Do you want the good news or bad
news?" "The good news is we've found out where these EHs that are
breaking your connections to us. The bad news is that while the people
who are doing it have asked their vendor for a fix, they're refusing
to switch it off, so you'll have to put up with it for the next 3 to 6
months."

Customer says, "Unfortunately, I realise that it isn't your fault,
however we can't put up with it for that long. We're going to have to
cancel your service and go with somebody else."

Now imagine if the one customer impacted was instead 10s of 1000s of
non-technical, residential customers - like the ones Google, Netflix
and Facebook have. Most of the above becomes impractical, and if this
problem persists for more than a few days, it'll likely cost you 10s
of 1000s of customers.

I've had experience troubleshooting issues over the Internet that have
effected my residential broadband customers (e.g., getting bogon
filter routes removed from remote networks because we'd been allocated
those addresses officially). That was a walk in the park compared to
what the above scenario would be like - my customers could identify
the website that they were trying to access.

Silent insertion, meaning non-attributable insertion, and failed
removal will be a nightmare to troubleshoot if those packets make it
onto the Internet - and they will, just like RFC1918 addressed packets
do. People who believe removal will always be performed successfully
are living in the fantasy that devices always perform perfectly, never
partially failing and programmers write perfect, bug free code.

Regards,
Mark.

---

From: Hemant Singh <[email-masked]>
Date: Tue, 22 Nov 2016 08:22:19 -0500

Note Tatuya Jinmei first emailed the mailer about SR on Linux:
http://www.segment-routing.org/index.php/SR/SR-IPv6

In his email, Tatuya mentioned this URL:
http://www.segment-routing.org/index.php/SR/SR-IPv6

The text at the bottom of the URL says:

"Note that the SRH may also be inserted into the packet without adding an
outer IPv6 header. This mode of operation is not documented in the IETF
draft, but our implementation supports it as there is demand from the
industry."

Hemant

---

From: Hemant Singh <[email-masked]>
Date: Tue, 22 Nov 2016 09:26:03 -0500

+1.

As I said in the past, this Inband OAM work has made it to a public-domain
Linux user space implementation in the FD.io code.

http://tinyurl.com/hx6kkry

The file names in ip6_hop* includes the Inband OAM code.

Also, a word to the authors of
https://tools.ietf.org/html/draft-brockners-inband-oam-transport-02.  The
IESG prefers a maximum of five authors for an I-D.  Your document has 11
authors.  Not that the document is ready for the IESG because it uses
in-situ EH-add in an IPv6 packet.

Hemant