Subject: Re: Proposed revised Extension Header text for rfc2460bis

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 May 2017 03:17:16 -0400

Hi Mark,

Were any changes required to the MPLS header or MPLS forwarding
> operations to support SR?
>

​If you would follow SR-MPLS you would realize that MPLS label carries an
embedded function. Exactly like SID in SRH.

Moreover with the overhead of signaling required to established an LSP in
MPLS case transit nodes no matter if they are within domain or beyond
domain DO NOT NEED to change any single bit in their current forwarding
paradigm. SR functions are executed only at the designated nodes which are
able to perform the desired forwarding behaviour.

This entire discussion that maybe we will bless SRv6 in closed domains just
does not get the fundamental point that transit nodes regardless on how
many SRH are in the IPv6 packet will work just fine. Of course there is MTU
concern ... but this concern is also with MPLS stacking or for that matter
with any encapsulation. And we do know today how to effectively solve it
when/where needed.

It get's even worse if you (like some of this WG members) now require to
encapsulate packets in additional v6 header before SRH is inserted - makes
zero sense ! Just please kindly observe that if you do the encap the dst
address can be anywhere in the Internet .. no encap code mandates that dst
must be in your IGP. So packets do escape ASes .. BGP in fact was
explicitly created to help/assist them to escape.

I think perhaps a dedicated interim meeting should be setup just to discuss
it and understand it well before we proceed with any further spec
clarifications or extensions.

Best,
Robert​

​PS. Leave alone other SRv6 features but does folks on this list do not
care about TI-LFA ?​

>
> Another difference between IPv6 and MPLS is that MPLS is not an
> end-to-end protocol, so it naturally creates and enforces local
> domains. To have MPLS frames successfully leak between two networks
> requires active enabling of MPLS on both ends of the links between
> them, which won't happen unless the MPLS networks explicitly agree to
> trade MPLS traffic, for explicit MPLS reasons, purposes and functions.
>
> IPv6 is an end-to-end protocol between hosts, that may transit
> multiple networks in between those hosts. IPv6 is brought up between
> two networks to provide services for any IPv6 applications. So SR
> wouldn't likely be the initial reason to enable IPv6 between two
> networks. Consequently, the likelihood of "internal" IPv6 SR packets
> going further than they should is naturally much higher. RFC1918 and
> similar have demonstrated that on the Internet, local or private "IP"
> domains aren't.
>
> Regards,
> Mark.
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 1 May 2017 12:00:54 +0000

Hi Mark,

>
    > Your SPRING group is operating in currently a very small green field (are
    > there any production deployments of SR yet?), ours is a very large brown
    > one. "Trivial" changes for you are trivial, for us we need to make sure they
    > don't break things in unexpected ways, because real and existing end-users
    > and production network operators may suffer a significant and potentially
    > financially costly consequence.
    >
    >
    >
    > Segment Routing is in production in Bell network (as explain at MPLS Paris
    > 2017) as well as for others operators for obvious reasons; simplicity and
    > “much needed innovation”.
    >
    
    Presumably MPLS based given the name of the conference?
    
    Are the slides anywhere?

Segment-routing.net is your next destination; under conferences and IETF.
    
 I recommend we go back to the purpose of this tread.

    Regards,
    Mark.
 
Thanks
dan

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 May 2017 10:40:35 -0700

On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk <[email-masked]> wrote:
> If you would follow SR-MPLS you would realize that MPLS label carries an
> MPLS case transit nodes no matter if they are within domain or beyond domain
> DO NOT NEED to change any single bit in their current forwarding paradigm.
> SR functions are executed only at the designated nodes which are able to
> perform the desired forwarding behaviour.
>
> does not get the fundamental point that transit nodes regardless on how many
> SRH are in the IPv6 packet will work just fine.

I don't understand why we'd expect this to "work just fine"... There
are still a lot of intermediate nodes that will arbitrarily drop
extensions headers. So if one device inserts an extension header in a
packet that previously had no extension headers and the packet is
dropped down stream by some other device, then the device inserting
headers has broken the end to end connectivity. What's worse is that
the offending device won't even know packets are being dropped so it's
can't do a happy eyeballs like algorithm like a host might be able to
do.

IMO, there is too much the emphasis here on the needs intermediate
nodes and the value add they might provide without regard to the needs
end hosts. IPv6 is, after all, a protocol that allow _hosts_ to
communicate which may be facilitated intermediate routers. The
assumption hosts make is that the IP packet sent from one host is
received "as-is" on the other with only specific modifications allowed
(options that may be modified in flight). In other words, if I, as a
host, send a packet into the network, I expect that same packet to pop
out at the receiver pretty much unchanged-- I don't expect the
receiver to get some ad hoc re-interpretation of the packet by network
nodes. This is implied by the robustness principle, fundamental to
security, and needed to maintain connectivity. If network nodes want
to modify packets in transit, insert extension headers, or other while
in transit that might be reasonable per the requirements as long as 1)
the changes are undone before delivering the packet to the receiving
host, and 2) there are no other insidious effects like unexplained
packet drop.

Tom

> Of course there is MTU
> must be in your IGP. So packets do escape ASes .. BGP in fact was explicitly
> created to help/assist them to escape.
>
> Robert
> PS. Leave alone other SRv6 features but does folks on this list do not care
> about TI-LFA ?
>
>
>>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 1 May 2017 10:47:52 -0700

At Sat, 29 Apr 2017 20:49:56 +0000,
"Stefano Previdi (sprevidi)" <[email-masked]> wrote:

> >> I also agree
> >> Using the standardized keywords avoids any *language-dependent*
> >> misunderstandings
> >
> > I also wish this document (both the latest bis and its predecessors)
> > had been using RFC2119 keywords, but the fact is that it hasn't, and
> > my recollection matches Brian's comment: we explicitly discussed it
> > before and the decision was not to use RFC2119 keywords for
> > rfc2460bis.  I don't think it productive to rehash the discussion at
> > this point.
>
> why not ?
> isn’t the point of a normative document to use normative language ?

I don't remember the exact key reason that brought us to that
decision.  That's something I just chose to live with, so I don't care
much about it at this stage.  If you think it's critical to turn over
the decision, I'd suggest you look into the email archive.

> >> Going back to the original discussion, I agree with Stefano's "should
> >> not" in this place
> >
> > I don't agree "should not" is an appropriate replacement of "are not”,
>
> but it’s an appropriate replacement text, looking at the reality of
> 2017 and not the one in 1998.
>
> > just like Brian and Fernando.  I also agree with Fernando in that it's
> > actually much closer to "must not", if anything.
>
> despite the various episodes, I still do not agree on the current text.

These two points seem to suggest you're essentially rehashing the very
original point of the discussion, i.e., whether we should clarify the
ambiguity in RFC2460 with the original intent.  In that case I'd
suggest you rather do so explicitly than pretend to make a minor
wording/editorial change.  Personally, I think it's more productive if
we ship rfc2460bis and focus on updates sooner rather than hold
rfc2460bis by rehashing the very original point of the discussion.
While in my case I support the current text of rfc2460bis, I made my
comment so we can be more productive and get things (including updates
to rfc2460bis) done sooner.  But apparently I failed in that attempt, so I'll
shut up here in this thread.

--
JINMEI, Tatuya

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 May 2017 14:17:45 -0400

Ok ... if v6 transit routers drop extension headers in spite of dst address
being not themselves to me this sounds like a bug.

It is behaviour against base v6 spec which allowed such EH to be inserted
into v6 packets by senders. Maybe bis spec should made it very clear and
mandate that transit routers MUST NOT alter EH in any way if the dst
address is not themselves.

Thx
R.

On May 1, 2017 10:40, "Tom Herbert" <[email-masked]> wrote:

> domain
> many

---

From: Fred Baker <[email-masked]>
Date: Mon, 1 May 2017 11:29:17 -0700

Indeed. My understanding of the complaint is that 
  - some routers may be configured with ACLs that enforce rules about extension headers, precluding any extension headers, specific types of extension headers, or limiting extension headers to certain types.
  - some routers may be configured with ACLs that worry about TCP/UDP port numbers, and drop packets for various reasons relating to the number of extension headers found, the IPv6 header actually fitting in working RAM in the chip, or other errors
  - if ACL handing is punted to another processor, it is often rate limited
  - firewalls, in particular, may be configured to worry about the presence of fragmentation headers

Those are indeed contrary to the specification, and if a router or firewall did it by default it would be in violation. That said, there are equipment limitations in some cases and operator configurations in others that can have the effect.

> On May 1, 2017, at 11:17 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Ok ... if v6 transit routers drop extension headers in spite of dst address being not themselves to me this sounds like a bug.
> 
> It is behaviour against base v6 spec which allowed such EH to be inserted into v6 packets by senders. Maybe bis spec should made it very clear and mandate that transit routers MUST NOT alter EH in any way if the dst address is not themselves.
> 
> Thx
> R.
>

---

From: "Leddy, John" <[email-masked]>
Date: Mon, 1 May 2017 18:36:43 +0000

The boxes you describe below would be considered “middle boxes”.

On 5/1/17, 2:29 PM, "ipv6 on behalf of Fred Baker" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Enno Rey <[email-masked]>
Date: Mon, 1 May 2017 20:51:28 +0200

Fred,

On Mon, May 01, 2017 at 11:29:17AM -0700, Fred Baker wrote:
> Those are indeed contrary to the specification, and if a router or firewall did it by default it would be in violation.

actually the majority of commercial enterprise firewalls perform some filtering of EHs, at least as for their number or order (which both are not restricted too much in RFC 2460), by default. These are results for some testing we did in 2014 (I doubt much has changed until today. if it has probably things have not become more flexible/liberal):
 
https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf

best

Enno

 That said, there are equipment limitations in some cases and operator configurations in others that can have the effect.

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 May 2017 15:46:39 -0400

Good thing that no one is putting firewall in global Internet transit DFZ.

So how this applies to this concern of transit nodes in the Internet remove
EHs ?

Cheers
R.

On May 1, 2017 11:54, "Enno Rey" <[email-masked]> wrote:

> >   - some routers may be configured with ACLs that enforce rules about
> extension headers, precluding any extension headers, specific types of
> extension headers, or limiting extension headers to certain types.
> >   - some routers may be configured with ACLs that worry about TCP/UDP
> port numbers, and drop packets for various reasons relating to the number
> of extension headers found, the IPv6 header actually fitting in working RAM
> in the chip, or other errors
> > Those are indeed contrary to the specification, and if a router or
> firewall did it by default it would be in violation.
>
> actually the majority of commercial enterprise firewalls perform some
> filtering of EHs, at least as for their number or order (which both are not
> restricted too much in RFC 2460), by default. These are results for some
> testing we did in 2014 (I doubt much has changed until today. if it has
> probably things have not become more flexible/liberal):
>
>  That said, there are equipment limitations in some cases and operator
> configurations in others that can have the effect.
> >
> > > Ok ... if v6 transit routers drop extension headers in spite of dst
> address being not themselves to me this sounds like a bug.
> > >
> > > It is behaviour against base v6 spec which allowed such EH to be
> inserted into v6 packets by senders. Maybe bis spec should made it very
> clear and mandate that transit routers MUST NOT alter EH in any way if the
> dst address is not themselves.
> > >
> > > Thx
> > > R.
> > >

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 May 2017 13:02:05 -0700

On Mon, May 1, 2017 at 11:17 AM, Robert Raszuk <[email-masked]> wrote:
> mandate that transit routers MUST NOT alter EH in any way if the dst address
> is not themselves.
>
That is not a requirement. EHs may be changed enroute per their
specification. For instance, HBH options include a flag to indicate
rather the option data may change in flight.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 May 2017 08:17:34 +1200

On 02/05/2017 05:47, 神明達哉 wrote:

...
>> despite the various episodes, I still do not agree on the current text.

The WG Chairs and AD have already declared a rough consensus, though.
 
> shut up here in this thread.

+1

     Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 1 May 2017 20:21:20 +0000

> On May 1, 2017, at 10:17 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> The WG Chairs

have declared rough consensus on another text, later changed by the AD.

s.

> and AD have already declared a rough consensus, though.
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 May 2017 15:27:06 -0700

On 5/1/17 12:46 PM, Robert Raszuk wrote:
> So how this applies to this concern of transit nodes in the Internet
> remove EHs ?

It would be rather odd for a device to attempt to remove Extension
Headers, it would be somewhat less surprising to see packets where the
l4 header cannot be found filtered, which applies to cases other then
for example new extension headers as well, for example non-initial
fragements.

In modern internet protocol routers, there are a number of reasons why
recourse to the L4 header might be practically required, these include
variously the application of control-plane acls (which may of course
include traffic set through rather than to the box),  the application of
forwarding plane acls (example 5575 bgp flowspec rules, static acls,
etc), hashing, needs to perform qos marking and so on.  in the cases
where an asic's lookup space precludes processing the extension header
chain, or where for other reasons the l4 header cannot be identified it
is clearly problematic to unconditionally forward the packet.

> Cheers
> R.
> 
> On May 1, 2017 11:54, "Enno Rey" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Fred,
> 
>     >   - some routers may be configured with ACLs that enforce rules
>     about extension headers, precluding any extension headers, specific
>     types of extension headers, or limiting extension headers to certain
>     types.
>     >   - some routers may be configured with ACLs that worry about
>     TCP/UDP port numbers, and drop packets for various reasons relating
>     to the number of extension headers found, the IPv6 header actually
>     fitting in working RAM in the chip, or other errors
>     actually the majority of commercial enterprise firewalls perform
>     some filtering of EHs, at least as for their number or order (which
>     both are not restricted too much in RFC 2460), by default. These are
>     results for some testing we did in 2014 (I doubt much has changed
>     until today. if it has probably things have not become more
>     flexible/liberal):
> 
>     <https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf>
> 
>     best
> 
>     Enno
> 
> 
> 
> 
> 
>      That said, there are equipment limitations in some cases and
>     operator configurations in others that can have the effect.
>     >
>     > > On May 1, 2017, at 11:17 AM, Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >
>     > > Ok ... if v6 transit routers drop extension headers in spite of
>     dst address being not themselves to me this sounds like a bug.
>     > >
>     inserted into v6 packets by senders. Maybe bis spec should made it
>     very clear and mandate that transit routers MUST NOT alter EH in any
>     way if the dst address is not themselves.
>     > >
>     > > Thx
>     > > R.
>     > >
>     > > On May 1, 2017 10:40, "Tom Herbert" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > On Mon, May 1, 2017 at 12:17 AM, Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > > > Hi Mark,
>     > > >
>     > > > [email-masked] <mailto:[email-masked]>
>     > > > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     > > >
>     > > [email-masked] <mailto:[email-masked]>
>     > > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     > [email-masked] <mailto:[email-masked]>
>     > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     <http://www.ernw.de>
>     Tel. +49 6221 480390 <tel:%2B49%206221%20480390> - Fax 6221 419008 -
>     Cell +49 173 6745902 <tel:%2B49%20173%206745902>
> 
>     Blog: www.insinuator.net <http://www.insinuator.net> || Conference:
>     www.troopers.de <http://www.troopers.de>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 May 2017 15:48:00 -0700

> is clearly problematic to unconditionally forward the packet.
It doesn't seem likely that this behavior is going to go away any time
soon, if ever. Maybe instead of just dropping packet these devices
should send back an ICMP error to inform the sender of which EH caused
the drop?

Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 May 2017 08:47:56 +1000

> mandate that transit routers MUST NOT alter EH in any way if the dst address

This is what RFC1883 said, which is also the text in RFC2460. It
literally says that, just without RFC2119 capitalisation.

   "With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header."

I struggle to see how that is ambiguous, unless some people are
confused by what the words and terms "are not", "examined" or
"processed" mean. That may be possible if English is not somebody's
first language, however I'd have thought they'd encountered those
words often enough in this field that it would be clear what they mean
e.g. the "Processing" in CPU.

Their meanings could be clarified, however any clarification would not
be changing the meaning of the statement.

A simpler version would have been:

"With one exception, extension headers are ignored by nodes along a
packet's delivery path, until the packet reaches the node (or each of
the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header."

So the RFC1883/2460 versions are already making clarifications that in
terms of English language meaning are unnecessary.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 May 2017 11:09:00 +1200

...
> should send back an ICMP error to inform the sender of which EH caused

Since unknown ICMPv6 is at high risk of being dropped too, this is
unlikely to help.

People, we discussed all this while RFC7045 was being drafted, and
many other times as well. What has it got to do with the final
wordsmithing of the IPv6 Internet Standard, where the technical
(rough) consensus is already known?

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 May 2017 19:10:55 -0400

Joel,

Valid observation especially since you quoted one of my own RFC ;)

But this issue may happen when src hosts inserts EHs. Also mandating one
more v6 encap to be able to add v6 EHs does not make the problem any easier.

ICMP error should be returned to src to report it indeed.

Do we have real numbers from deployed boxes in Internet DFZ how deep L4 can
be from the start of the packet to still be readable ? Or are we just
speculating here that it may happen ?

Thx,
R.

On May 1, 2017 15:27, "joel jaeggli" <[email-masked]> wrote:

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 May 2017 16:35:33 -0700

> (rough) consensus is already known?
Brian,

The wording in RFC2460bis is:

"Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, until the packet reaches the node"

Inserted or deleted are not common operations so maybe they can be
squashed, but in the Internet extension headers _are_ being processed
in modern Internet routers as Joel said, if nothing else to find the
transport header. It's hard to rectify the standard against this
reality other than to not use an EH at all which is pretty much where
hosts are currently.

Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 May 2017 10:09:43 +1000

> ICMP error should be returned to src to report it indeed.

This is one of the issues with EH insertion. The device that inserted
the EH is not recorded in the packet. The only source device recorded
in the packet is in the Source Address field, but that clearly isn't
the source of the inserted the EH.

An additional IPv6 encapsulation adds that missing information. If the
EH is added via:

[New IPv6 HDR][New EH][Original IPv6 packet]

then it is clear that the source address in the [New IPv6 HDR]
identifies the device that added the [New EH], and if any errors are
encountered because of the new EH, then they're correctly sent to the
source device identified in the [New IPv6 HDR].

While an inserted EH is present, the Source Address field value is not
accurate anymore. If RFC2460 was changed to allow EH insertion, then
there also has to be changes made to state that the Source Address
field doesn't always accurately record the source device of all of the
contents of the packet while in-flight or when the packet arrives at
the destination host. Anything else that is making that assumption
e.g., PMTUD, ICMP, IPsec AH also would needs to be updated with that
change and the consequences evaluated.

Regards,
Mark.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 May 2017 17:50:39 -0700

On 5/1/17 4:10 PM, Robert Raszuk wrote:
> Do we have real numbers from deployed boxes in Internet DFZ how deep L4
> can be from the start of the packet to still be readable ? Or are we
> just speculating here that it may happen ?

Juniper Martini (router) ASICs circa 2000 were as shallow as 52 bytes
(it's not really surprising where that number came from). A broadcom
jericho asic which is  modern cell forwarder suitable for a high end
(full fib in many cases) layer 3 ethernet switch such as the nexus 9000
or arista 7500 can look in 128 byte, asr9k or mx trio router silicon can
do 192 or 384 respectively. typically these devices might potentially
have to account for an mpls or l2 header also depending on how they are
used.

> Thx,
> R.
> 
> 
> 
> On May 1, 2017 15:27, "joel jaeggli" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > On May 1, 2017 11:54, "Enno Rey" <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >
>     >     Fred,
>     >
>     >     >   - firewalls, in particular, may be configured to worry
>     about the
>     >     presence of fragmentation headers
>     >     >
>      <https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf
>     <https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf>>
>     >
>     >     best
>     >
>     >     Enno
>     >
>     >
>     >
>     >
>     >
>     >     > > On May 1, 2017, at 11:17 AM, Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >     > > > Hi Mark,
>     >     > > >
>     >     > > > If you would follow SR-MPLS you would realize that MPLS
>     label
>     >     carries an
>     >     > > > MPLS case transit nodes no matter if they are within
>     domain or
>     >     beyond domain
>     >     > > > This entire discussion that maybe we will bless SRv6 in
>     closed
>     >     domains just
>     >     > > extensions headers. So if one device inserts an extension
>     header
>     >     in a
>     >     > > nodes and the value add they might provide without regard
>     to the
>     >     needs
>     >     > > host, send a packet into the network, I expect that same
>     packet
>     >     to pop
>     >     > > to modify packets in transit, insert extension headers, or
>     other
>     >     while
>     >     > > in transit that might be reasonable per the requirements
>     as long
>     >     as 1)
>     >     > > > concern ... but this concern is also with MPLS stacking
>     or for
>     >     that matter
>     >     > > > It get's even worse if you (like some of this WG
>     members) now
>     >     require to
>     >     > > > must be in your IGP. So packets do escape ASes .. BGP in
>     fact
>     >     was explicitly
>     >     > > >> them, which won't happen unless the MPLS networks
>     explicitly
>     >     agree to
>     >     > > >> multiple networks in between those hosts. IPv6 is
>     brought up
>     >     between
>     >     > > >> networks. Consequently, the likelihood of "internal"
>     IPv6 SR
>     >     packets
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > > > Administrative Requests:
>     >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >     > > >
>     >   
>     >     > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     > > Administrative Requests:
>     >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >     > >
>     >     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     > Administrative Requests:
>     >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >     >
>     >     Tel. +49 6221 480390 <tel:%2B49%206221%20480390>
>     <tel:%2B49%206221%20480390> - Fax 6221 419008 -
>     <tel:%2B49%20173%206745902>
>     >
>     >     Blog: www.insinuator.net <http://www.insinuator.net>
>     <http://www.insinuator.net> || Conference:
>     >     www.troopers.de <http://www.troopers.de> <http://www.troopers.de>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     Administrative Requests:
>     >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>     >

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 May 2017 11:34:16 +1000

Hi Tom,

>>> On Mon, May 1, 2017 at 3:27 PM, joel jaeggli <[email-masked]> wrote:

<snip>

> reality other than to not use an EH at all which is pretty much where

I think what this comes down to is what the fundamental purpose or
purposes of the specification is.

I think the fundamental purposes of network layer specifications like
RFC2460 are:

- to define required and possibly optional protocol parameters and
operations for functions/devices in the network and functions/devices
that use the network

- to specify network user or client function/device (a.k.a. host)
expectations of the service provided by the network

A router (as a function) doesn't need to be able to look much past the
fixed IPv6 header (the one exception being the HBH header) to meet the
specification definition of an IPv6 router ("a node that forwards IPv6
packets not explicitly addressed to itself").

A router as a device may do other things that may exceed the
specification as a "value add", however the outcomes of those
operations, even when they fail, needs to be consistent with the
service expectations of the network users/client functions/devices. I
don't think we also need to include this "value add" as part of the
base specification, as it isn't required for the base specification to
achieve its goals.

Regards,
Mark.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 1 May 2017 22:52:00 -0400

Hi Stefano,

> have declared rough consensus on another text, later changed by the AD.

You make it sound like I changed it because I felt like it :-). I
instructed the editor to change the text directly as the result of the
IETF Last Call consensus. (and to be very frank, the WG consensus was
pretty rough to start off with). I got the WG mailing list looped in
on the IETF Last Call discussion as soon as this issue came up. I
copied the IETF last call conclusion to the WG mailing list. The WG
has had a chance to have a say every step of the way. The objection to
this new text has always been "We have a proposal that will end up
violating this restriction, so let's make it a should not". The header
insertion proposal (draft-voyer-6man-extension-header-insertion-00)
was not even written up until couple of weeks after the IETF Last Call
on RFC2460bis concluded. As I said in my mail below

https://www.ietf.org/mail-archive/web/ipv6/current/msg26934.html

I am expecting the proponents of header insertion to do exactly what
the proponents of zero UDP checksums did and do the groundwork for
updating RFC2460bis. I will do my part by sending in my review for
that draft (draft-voyer).

Thanks
Suresh

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 2 May 2017 11:58:17 +0000

> On May 2, 2017, at 4:52 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Stefano,
> 
> You make it sound like I changed it because I felt like it :-).

no Suresh, I didn't mean that. I just related the fact and that what’s happened after all.

Thanks.
s.

> I

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 May 2017 15:43:13 +0000

Hi,

> On 2 May 2017, at 00:35, Tom Herbert <[email-masked]> wrote:
> 

But the word “examined” was removed from the above quoted text, for that reason.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 May 2017 15:46:39 +0000

Hi,

> On 2 May 2017, at 03:52, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Stefano,
> 

It would be good to spend our cycles focusing on this, rather than extended filibustering on 2460bis.

We have (rough) consensus; let’s get 2460bis published as IS and move on to progressing draft-voyer-6man-extension-header-insertion.

Tim