Subject: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

From: Suresh Krishnan <[email-masked]>
Date: Wed, 15 Mar 2017 02:47:06 +0000

Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.  The only argument made against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change.

OLD (from -08):

 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]

 With one exception, extension headers are not 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...

NEW:

 With one exception, extension headers are not examined, processed,
 inserted, or deleted 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...

Please feel free to comment either privately or on list if you have any concerns with this resolution going forward.

Regards
Suresh

P.S.: There were also other editorial issues that were raised during last call and they should be addressed in the next version of the draft

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 15 Mar 2017 15:55:00 +0000

Suresh,

I appreciate your effort and I’m obviously interested into finding a way out from this issue.

To my view, due to the work that has been initiated in drat-ietf-6man-segment-routing-header and recently in draft-filsfils-srv6-network-programming, the current text of RFC2460 (i.e., not the “bis” version) is good enough.

RFC2460 section 4 states:

   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.

Now, RFC2460 has been written almost 20 years ago and since then, both technology and network operators requirements have evolved.

We do have today use cases where not only the source of a packet should be allowed to insert a header but also the source “domain” of a packet. I’ll try to explain.

In a domain controlled by a single organization (typically the set of ASs under control of the same operator) a packet enters at the edge where the ingress node applies a policy resulted into an additional outer ipv6 header that may or may not contain an extension header. Bottom line, the outer header means that now, it is a NEW packet, originated by the ingress node, with SA/DA representing the nodes that are inside the operator domain. Therefore, we can say that this new packet (formed by an outer header and encapsulated original packet) is now owned by the operator and whatever the operator does with this packet:

. The packet MUST leave the operator network in the exact same shape/format as it entered (i.e.: outer encapsulation removed).
. The outer header MAY change while in transit in the operator’s domain. Moreover, a header MAY be inserted while inside the operator’s domain (knowing that outer header and any other inserted header would be removed at egress). This means that an SRH MAY be inserted at the same time the outer header is added but it can also be that the ingress adds the outer header and some other node inserts an SRH (e.g.: fast reroute within operator’s infrastructure).
. While in transit, the operator network must handle aspects like MTU properly, taking into account the increased size of the packet.

So, this use case enlarge the rule for header insertion.

Originally RFC2460 stated that only the source of the packet is entitled to add an EH. Now we’re going to propose that the source “domain” of the packet is allowed to insert EHs. The source domain being the set of nodes (including the ingress node adding the outer header) under common administration. This also implies that when the packet leaves the domain, it must recover its original format/shape.

In order to have a more productive discussion, we are writing a draft on header insertion that will be submitted as soon as the windows re-open (during ietf week).

In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what to do with EH insertion.

Thanks.
s.

> On Mar 15, 2017, at 3:47 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> P.S.: There were also other editorial issues that were raised during last call and they should be addressed in the next version of the draft--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2017 05:16:55 +1300

Stefano,
On 16/03/2017 04:55, Stefano Previdi (sprevidi) wrote:
...
> In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what…

I believe that we have figured it out: extension header insertion is harmful to Internet interoperability.

I fully agree with Suresh's understanding of the rough consensus.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 15 Mar 2017 16:21:34 +0000

Hi,

> On 15 Mar 2017, at 16:16, Brian E Carpenter <[email-masked]> wrote:
> 
> Stefano,

I also agree with Suresh’s appraisal. 

Tim

---

From: "Leddy, John" <[email-masked]>
Date: Wed, 15 Mar 2017 16:33:32 +0000

Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain?

John

On 3/15/17, 12:21 PM, "ietf on behalf of Tim Chown" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    Tim

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Mar 2017 10:16:23 -0700

At Thu, 16 Mar 2017 05:16:55 +1300,

> I fully agree with Suresh's understanding of the rough consensus.

I also support Suresh's proposal.

BTW,

At Wed, 15 Mar 2017 15:55:00 +0000,
"Stefano Previdi (sprevidi)" <[email-masked]> wrote:

>> Originally RFC2460 stated that only the source of the packet is
>> entitled to add an EH. Now we’re going to propose that the source
>> “domain” of the packet is allowed to insert EHs. [...]
>>
>> In order to have a more productive discussion, we are writing a
>> draft on header insertion that will be submitted as soon as the
>> windows re-open (during ietf week).

IMHO this plan explains exactly why we rather need to make it more
explicit in rfc2460bis that this version of spec does not assume EH to
be inserted or deleted except at the source node (not "domain").  I'm
totally open to the discussion of possible extensions with the concept
of "source domain".  But it should be fair to say it will take time,
at least for months, and quite likely more than a year.  If we keep
the rfc2460bis text "ambiguous" in the meantime, we'll leave the risk
that it's interpreted more loosely and someone develops an
implementation that violates the assumption more casually.  To me,
it's more responsible to be more explicit in the current specification
to prevent further accidental misunderstanding unless and until we
have the possible revised conditions.

--
JINMEI, Tatuya

---

From: "Voyer, Daniel" <[email-masked]>
Date: Wed, 15 Mar 2017 17:57:37 +0000

> . While in transit, the operator network must handle aspects like MTU properly, taking into account the increased size of the packet.
DV: I concur with this explanation & needs.
> In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what…

DV: I support this recommendation, especially that there will be a document submitted in 2 weeks, stated here, that will add more context. Which position the WG good discussion.

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Mar 2017 11:12:25 -0700

Stefano,

Your case below falls under the "acting on behalf of the endpoint"
approach, IMO.

I'm comfortable with the current proposed resolution, which IMO allows
for enterprises to "create" the IP header in whatever distributed system
they want.

The only rule is simple: that enterprise must act like a host in total,
i.e., it must follow node requirements.

If you do that, then nobody will care how you implement header creation.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Mar 2017 11:14:10 -0700

> Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain?
Please see my recent post about Stefano's issue. IMO, any opaque
(distributed) system that acts like a host can follow the host (node)
requirements.

The instant that system is not opaque or fails to act like a single
host, it becomes noncompliant.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Mar 2017 15:48:47 -0300

+1

El 15/3/2017 13:17, "Brian E Carpenter" <[email-masked]>
escribió:

> > In the mean time, I think it is way too premature to come to conclusion
> on what text should be used for RFC2460bis and I recommend that the current
> text is left unchanged until we figured out what to do with EH insertion.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2017 07:59:31 +1300

> host, it becomes noncompliant.

That's the point. That's why the 6man WG shot down proposals to play
intra-domain tricks with the flow label a few years ago, and they
didn't even break PMTUD or IPsec/AH.

In another form, the answer to John is that there are no protocol police,
so what consenting adults do inside their own networks simply isn't an
issue that an Internet-wide spec can or should address. And for sure, the
spec for IPvN for any value of N is an Internet-wide spec.

If Stefano and colleagues describe how private domains can perform tricks
that MUST NOT be exported to the Internet, that is fine. Whether that
becomes a standards track document or an Independent Submission RFC is
another question. But IMHO it is completely orthogonal to the rough
consensus on 2460bis.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Mar 2017 13:34:15 -0700

Agreed.

Joe

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Mar 2017 07:38:58 +1100

> I believe that we have figured it out: extension header insertion is harmful to Internet interoperability.

I and others were going to work on an ID describing why, however the
other co-authors seem to have disappeared. I'll start putting together
what I have over the next week.

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Wed, 15 Mar 2017 23:30:23 +0000

> On 15 Mar 2017, at 18:59, Brian E Carpenter <[email-masked]> wrote:
> 

Exactly.

Tim

---

From: Xing Li <[email-masked]>
Date: Thu, 16 Mar 2017 09:12:02 +0800

> another question. But IMHO it is completely orthogonal to the rough

+1, xing

---

From: [email-masked]
Date: Thu, 16 Mar 2017 09:11:48 +0100

Guys,

Please hold your horses. The AD has made the call. I don't think we need to have a poll on that.

Cheers,
Ole

> On 15 Mar 2017, at 03:47, Suresh Krishnan <[email-masked]> wrote:
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Mar 2017 10:44:35 +0000

> issue that an Internet-wide spec can or should address.

That is not quite true, the inability to gain an IANA allocated 
codepoint can make long
term private deployments very difficult, either for the protocol 
squatting on a codepoint
because they could not get one allocated, or to the deployment of a new 
protocol
legitimately allocated a conflicting codepoint.

- Stewart

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 16 Mar 2017 12:40:53 +0000

Thanks Stewart,

This really supports my point and hopefully not the intent or result of the discussions here.

We are trying to work through the IETF process to come up with standards and solutions that address real operational challenges faced in deployments.  For operators, dealing with legacy and migrations are a big challenge.

Wishing these issues away and as a result having non-standard functionality in “middle boxes” that are ignored in the architecture is not productive.  NATs are a way of life, dark space is being deployed by other operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels, tunnels everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way down”.

We are very aggressively migrating to a V6 infrastructure, but there is a large amount of old legacy systems/applications/services that need to be addressed.  At the same time the allure of “Cloud” attracts systems that should never be moved without being re-architected and the virtualization environments fully supporting V6 (both Vendors and OpenSource) – but they do move and vendors help make that possible.

Hopefully we can keep the discussions going and keep tools available until we know we have solutions to deal all the activity happening outside a clean end-to-end Architecture,

John

    
    
    - Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Mar 2017 18:06:50 +0100

All,

This is very interesting thread indeed.

I think header insertion at *any* network element be it host, router,
service chain device is highly desired. IPv6 deployments will be much more
successful if we clear any obstacles which otherwise prevent it from
delivering required by customers and operators functionality.

And I would state that this should be not only limited to one's own IGP or
BGP domain. It should be legal Internet wide.

Today Internet as a entire system lacks tools to accomplish path
engineering, fast connectivity restoration, p2mp delivery of content etc
... Some of those are possible with MPLS based tools however as we all know
MPLS has no NNI and does not really work across domains. Here we stand very
close to have a chance to fix it.

And if one would forbid by spec the header insertion performed by network
elements what's the alternative ... IPv6 in IPv6 encapsulation which may
suffer with even more overhead yet will still require IANA allocation of
SRH type as well as TLV codepoints as effectively encapsulating network
element will be acting as IPv6 sender.

Concluding I do hope that we can try to collectively make IPv6 protocol
flexible enough to satisfy customer and operator's requirements what in
turn will enrich and speed up IPv6 global adoption.

Kind regards,
Robert.

On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <[email-masked]> wrote:

> We are trying to work through the IETF process to come up with standards
> and solutions that address real operational challenges faced in
> deployments.  For operators, dealing with legacy and migrations are a big
> challenge.
>
> Wishing these issues away and as a result having non-standard
> functionality in “middle boxes” that are ignored in the architecture is not
> productive.  NATs are a way of life, dark space is being deployed by other
> operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels, tunnels
> everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way
> down”.
>
> We are very aggressively migrating to a V6 infrastructure, but there is a
> large amount of old legacy systems/applications/services that need to be
> addressed.  At the same time the allure of “Cloud” attracts systems that
> should never be moved without being re-architected and the virtualization
> environments fully supporting V6 (both Vendors and OpenSource) – but they
> do move and vendors help make that possible.
>
> Hopefully we can keep the discussions going and keep tools available until
> we know we have solutions to deal all the activity happening outside a
> clean end-to-end Architecture,
>
> John
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Mar 2017 11:51:12 +1300

Robert,

(cc's trimmed)

I remember well, back when serial modems were still the norm, sitting
in hotel rooms manually cranking back the IPv4 MTU size on my laptop
until it was possible to establish TCP connections. Fortunately,
somebody had written a piece of freeware that made this possible on
Windows 95. I seem to remember having to set the MTU to 256 in Vienna,
for example.

It is really unthinkable to me to allow header insertion on the Internet
until we have a working solution to PMTUD in all circumstances, which we
don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB,
and due to RFC4821 being a rarity. 

When this major operational problem has been solved, it will be time to
seriously consider header insertion (including its very non-trivial
security implementations).

Regards
   Brian Carpenter

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 18 Mar 2017 00:11:49 +0100

Hello Brian,

I do suffer from MTU issues over both intranets and Internet the same way
as you do ... or maybe even more.

As example there are transit ISPs out there who provide now extra new fancy
services of DDoS detection except they do not tell that to direct your data
stream packets to screening devices they encapsulate it in another entire
IP header to redirect it to this service.

MPLS encapsulation is also another one. While other then 6PE it happily
leaves v6 Internet alone there are active proposals in IETF to take it on
target as well.

However allowing or not allowing header insertion into IPv6 is IMHO
orthogonal here. The fact that you forbid it will only result in bigger
size encapsulation hence lower effective MTU. Services have moved to
overlay and that requires decoupling them from transport. And in some
networks service is not just fancy firewall or load balancer ... service is
basic IPv4 lookup, basic VPN segmentation or tenant micro segmentation. And
the last one even if it starts on end host it starts not in sourcing VM,
but in the forwarding host OS kernel's RIB.

MTU is a valid problem and we should work on it but I don't think it should
stop IPv6 based services and IPv6 innovation till it is solved. I can use
today SRv6 features in my data centers where I consistently know that all
interfaces are set for jumbo frames and where hopefully I do not need to
worry about MTU since hosts have much lower max MTU configured.

Kind regards,
Robert.

On Fri, Mar 17, 2017 at 11:51 PM, Brian E Carpenter <
[email-masked]> wrote:

> >>     > so what consenting adults do inside their own networks simply
> isn't
> >> an

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Mar 2017 14:10:51 +1300

> I can use

Exactly. That's not the Internet. Internet Standards are for the Internet,
hence I believe that the AD's decision is the correct one.

(How would you feel about an extension header that MAY be deleted
by an intermediate node, and MUST be deleted if the next hop's link
MTU is too small? That's the sort of complexity that allowing header
insertion would require in order to be acceptable across the Internet
with broken PMTUD that we have. Also PTB semantics would have to change
from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since
the source has no idea how much has been added by intermediate systems.
Or perhaps the intermediate systems would have to send back a new
ICMPv6 message saying "I extended your packet by Y bytes." This is
not straightforward.)

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Mar 2017 12:31:11 +1100

> ICMPv6 message saying "I extended your packet by Y bytes." This is

And that may not work anyway, because some security people believe all
ICMP is evil.

The Linux kernel has had an implementation of PLPMTUD since 2006, so
it is now literally in billions of devices, however it is switched off
by default. I've commonly switched it on over the years* and never
encountered a noticeable issue when I have (i.e., I've never had an
issue that has made me suspect a PMTUD problem and caused me to
investigate, and I've always been on a dumbell MTU PPPoE setup since
getting broadband 15 years ago.)

Would a BCP saying to implement it or enable it if already be
implemented in hosts be a better approach to encourage its adoption,
rather than just continuing to accept the status quo of hosts that
can't perform PMTUD successfully because of broken networks?

Regards,
Mark.

*
# net.ipv4.tcp_mtu_probing sysctl
#tcp_mtu_probing - INTEGER
# Controls TCP Packetization-Layer Path MTU Discovery.  Takes three
# values:
#  0 - Disabled
#  1 - Disabled by default, enabled when an ICMP black hole detected
#  2 - Always enabled, use initial MSS of tcp_base_mss.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 18 Mar 2017 10:15:54 +0100

Hi Brian,

> hence I believe that the AD's decision is the correct one.

​Well I don't know .. Protocols are used both in the open Internet and in
the contained ​environments. Hence IANA allocations and draft progress
should be encouraged regardless if something is to be deployed in the
Internet or not.

Now as customer I do encourage multi-vendor networks even for closed
RFC1918 private WAN, MAN or DCs.

If we just drop and position IETF to work on "Internet" only use cases
where would interoperability of routing protocols and beyond fall under ?
Which SDO ?

> MTU is too small?

​Well SRH can be applied both as a mission critical or optimization. If it
is an optimisation ​indicated in the packet by a flag I would be fine to
remove it if it does not fit to the MTU of the link.

If it is however "MUST HAVE" for a given flow I would rather see a packet
drop then to continue forwarding without it.

Both such events should indeed be signaled to the "owner" of the SRH or any
other extension header either inbound via for example ICMPv6 or maybe by
some other targeted message or indicated out of band (via logging to
syslog) - applicable to single administration domain.

​Kind regards,
Robert.​

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Mar 2017 01:57:23 +1300

> should be encouraged regardless if something is to be deployed in the

That's true, and that's why I'm very open to the idea of local-use
allocations in general. But for the IP protocol above all, we need
Internet-wide interoperability in the Internet Standard.

    Brian

---

From: Timothy Winters <[email-masked]>
Date: Sat, 18 Mar 2017 14:00:25 +0000

Hi Mark,

We are working on an updated IPv6 node requirements, that might be a good
place to put this type of suggestion.

The current text says
" One operational issue with Path MTU Discovery occurs when firewalls

   block ICMP Packet Too Big messages.  Path MTU Discovery relies on
   such messages to determine what size messages can be successfully
   sent.  "Packetization Layer Path MTU Discovery" [RFC4821] avoids
   having a dependency on Packet Too Big messages

I'm guessing we might want to put something more the this?

Tim

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Mar 2017 11:34:23 -0400

Brian E Carpenter <[email-masked]> wrote:
    > It is really unthinkable to me to allow header insertion on the
    > Internet until we have a working solution to PMTUD in all
    > circumstances, which we don't, due to operators misconfiguring
    > middleboxes to drop ICMPv6/PTB, and due to RFC4821 being a rarity.

In this debate we have seen essentially four arguments:

1) insertion is bad because <appeal to authority>
2) insertion is bad because PMTUD
3) insertion is bad because IPsec AH
4) insertion is bad because other ICMP issue/hard-to-diagnose weirdness

Perhaps we will agree that (1) is not an argument.
My claim is that (3) is irrelevant, IPsec AH has sadly (very very sadly from
my point of view) failed.

The PMTUD argument would be persuasive for me if PMTUD via ICMP really
worked. My experience is that there are just way many problems.  PLPMTUD
has been the only way I've gotten IPv6 over IPsec tunnels (where there is an
MTU constriction) to work consistently, and I had argued that 2460bis should
standardize this rather than PMTUD.

As for point (4), I think that we have a general problem here regardless of
insertion.  It would be nice to come up with some solutions to the problems
of insertion, noting that insertion is just something that shines light
on a fundamental problem.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Mar 2017 04:57:39 +1300

> Perhaps we will agree that (1) is not an argument.

No, but the point is a bit more subtle. It's very clear to people who were
there that the *intention* of RFC1883 and 2460 was to forbid insertion,
so changing this (rather than clarifying it) during the promotion to
Internet Standard would be against the IETF's process rules.

You can claim that is a weak argument, but it is an argument.

> my point of view) failed.

Yes. But if you want to leave the way clear for defining a non-failing
alternative to AH, we would need inserted headers to be excluded from
AHng, which means some new design, I think.

> standardize this rather than PMTUD.

Right, but my understanding is that packets that grow in transit would break
PLPMTUD as well (at least temporarily).

> on a fundamental problem.

Well, ICMP misrouting is kind of intrinsic in a connectionless datagram network
with "transparent" middleboxes that mess with packets. I think you could spend
the rest of your life failing to fix that.

Writing local-use provisions for domains with very large internal MTUs is more
practical, once we have 2460bis out of the way, IMHO.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Mar 2017 13:18:12 -0400

A) The AD has made the call.  We should re-litigate on the ipv6 list a 
discussion and conclusion from the IETF list.

B) My argument was not about whether insertion was in and of itself 
disastrous (although I do personally think it is a very bad idea). 
Rather, my argument has been that the current text is unclear.  Some 
folks read it as permitting insertion.  Other folks read it as 
prohibiting insertion.  Unclear text, particularly for advancment to IS, 
is just not acceptable.

I only include B in this note because you chose to describe the 
arguments being made.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Mar 2017 14:39:26 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> My claim is that (3) is irrelevant, IPsec AH has sadly (very very
    >> sadly from my point of view) failed.

    > AHng, which means some new design, I think.

The failure of AH across the Internet has nothing to do with the AH construct
itself.   It has to do with the failure to establish any kind of useable
Internet-wide trust infrastructure anchored in ownership of IP addresses.

You can't use AH to secure interesting headers across the Internet if you
can't establish trust to do the key management.

{IPsec ESP is equally a failure for Internet-wide usage, except that it is
useful for VPNs and Remote access scenarios in which trust can be established
in the small}

Given that the alternative to header insertion is IPIP insertion, if one
wants to protect headers, one can often use ESP equally well.  The one
advantage of AH was that one was sure that the stuff inside (after) the AH
is unencrypted.  This matters to firewalls and other auditing devices that
wish to validate a flow, but not interfere with one.

    >> worked. My experience is that there are just way many problems.
    >> PLPMTUD has been the only way I've gotten IPv6 over IPsec tunnels
    >> (where there is an MTU constriction) to work consistently, and I had
    >> argued that 2460bis should standardize this rather than PMTUD.

    > Right, but my understanding is that packets that grow in transit would
    > break PLPMTUD as well (at least temporarily).

Correct, but a path change also can cause such a thing, as can a lot of other
things.

    >> As for point (4), I think that we have a general problem here
    >> regardless of insertion.  It would be nice to come up with some
    >> solutions to the problems of insertion, noting that insertion is just
    >> something that shines light on a fundamental problem.

    > Well, ICMP misrouting is kind of intrinsic in a connectionless datagram
    > network with "transparent" middleboxes that mess with packets. I think
    > you could spend the rest of your life failing to fix that.

My point is that we need tools that let us investigate problems that occur in
the middle of the network.  Particularly, in the middle of other people's
networks.   For instance, there are (have been?) bugs in some ECMP solutions
that basically kill any TCP connection that lasts longer a few minutes.
Nobody using HTTP ever notices...

---

From: Christian Huitema <[email-masked]>
Date: Sun, 19 Mar 2017 23:04:53 -0700

> Internet-wide trust infrastructure anchored in ownership of IP addresses.

It also has to do with the undesirability of using IP addresses as long
term identifiers. The concept of "trust infrastructure" implies some
degree of stability in the identifiers. This is exactly what you don't
want if you are concerned with privacy.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Mar 2017 10:17:56 -0400

Christian Huitema <[email-masked]> wrote:
    >> The failure of AH across the Internet has nothing to do with the AH
    >> construct itself.  It has to do with the failure to establish any kind
    >> of useable Internet-wide trust infrastructure anchored in ownership of
    >> IP addresses.

    > want if you are concerned with privacy.

That's a good additional reason why we can't build long-term trust on IP
addresses.   Short-term trust (for durations of minutes to a few hours)
does not seem to be as big an issue.  Afterall, we do this all the time
with TCP SYN/ACK three way handshake.

And, notice that I didn't actually say that... I said "in ownership of IP
addresses"... I would prefer to be able to map IP address-->ASN, and
then see how that could map to an operator's public key.  And then
throw in v6PD and homenet users, and...

(hey, stop laughing! A crypto-geek can dream, can't he?)

The point is that AH for protection of headers is dead because we don't have
one of those.  And if you aren't protecting headers, then you can/should use
ESP. (or as people actually do: TLS)

So I'm just not worried about breaking AH.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Mar 2017 11:44:55 +1300

On 21/03/2017 03:17, Michael Richardson wrote:
...
> So I'm just not worried about breaking AH.

That's well understood for today's AH. What bothers me is that
if we allowed en-route changes to headers now, without thinking this
aspect through, we might make any future AH-like authentication
mechanism impossible too. So at a minimum, we'd have to be sure
that inserted, modifiable and deletable headers are marked in some
way that will allow them to be excluded from authentication. That
was thought about years ago for IPv6 options, but not for extension
headers.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Mar 2017 10:57:13 -0400

Brian E Carpenter <[email-masked]> wrote:
    > On 21/03/2017 03:17, Michael Richardson wrote: ...

    > That's well understood for today's AH. What bothers me is that if we
    > allowed en-route changes to headers now, without thinking this aspect
    > through, we might make any future AH-like authentication mechanism
    > impossible too. So at a minimum, we'd have to be sure that inserted,
    > modifiable and deletable headers are marked in some way that will allow
    > them to be excluded from authentication. That was thought about years
    > ago for IPv6 options, but not for extension headers.

a) AH was invented in the early 1990s, and was a response to the realization
   that we might not get a cryptographic system out of the US that included
   encryption.

b) it has never been useful for authenticating IPv6 headers.  The one time
   that we got close was SEND, and we specified the "unknown SPI" behaviour
   wrong so we couldn't do SEND as AH+ICMP unless we had a flag day.

c) I would claim that the headers that would most benefit from being
   authenticated would ones inserted mid-path :-)
   That argues actually for IPIP encapsulation of those headers so that
   the trust anchor is the IPv6 src address. (but, AH SPI# are allocated by
   destinations, not senders, so AH is also wrong for that)

   But, we have inadequately documented IPIP header decapsulation by end
   hosts, explaining that they should ignore AH (or AHng) headers that they
   do not understand.

d) does 7045 even give us enough power to create AHng?  I didn't read it
   that way.

I'm just not convinced that "breaks IPsec" is a valid concern.
(And I weep saying this)

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 30 Mar 2017 02:59:01 +0000

> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <[email-masked]> wrote:
    > 
    > NEW:
    > 

Suresh,

I still have concerns that we are eliminating a tool that may prove very helpful in migrations without understanding its value.

The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has been long, operationally complex and full of unexpected challenges.
We are only now starting to make the transition from Dual Stack to IPV6 Only, there are still many unknowns on how to complete this migration.

As we contemplate finishing this major Network shift – We find ourselves in the early stages of another.

The transition from Physical to Virtual Infrastructure.  Again, the migration will be long, operationally complex and full of unexpected challenges.

In the old world with Servers running Applications in Physical locations designed for very predictable loads; using an encap/decap tunnel to emulate a physical circuit between locations has many attractive properties – but that is compared to actually ordering and provisioning real circuits between locations.

In the new world of dynamic resources spun up on demand in distributed environments across multiple providers, Applications having the Intelligence and State to bring up their own required connectivity is very natural.  This is where we are putting the majority of our efforts.  SRv6 enables very attractive solutions by Applications building their own headers.

The challenges come as we try to migrate and require these two infrastructures to Interoperate for a long time.
Burdening the new Virtual world with Old, Static circuit paradigms is not optimal.
Supplementing the legacy infrastructure with an assist function seems a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap tunnels)

The preferred assist mechanism seems to be the one that allows the New World to operate in its final preferred state, sending and receiving packets with their own headers. (SRv6)
But what does an Application in the new world due when it is attempting to communicate with an Application in the Old World?
Shouldn’t it build an SRv6 header?  That would mean that the assist function would need to be the last SID in the Segment List and be capable of removing the SRH.
Wouldn’t it make sense for the assist function to do the same thing in the reverse direction; an Old World Server talking to a New Virtual World Application?  Insert an SRH.

If this insert/delete of an SRH is prematurely prohibited;  What is a recommended solution to the Real World problem above.  Not use case, we are implementing.

Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking,

Thank you for asking and listening to my concerns,

John Leddy
Comcast

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 06:09:37 +0100

Hi,

> On 30 Mar 2017, at 03:59, Leddy, John <[email-masked]> wrote:
> 

Understood, but why do you require direct insertion rather than using encap as per 2460bis?

Tim

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Mar 2017 04:30:51 -0500

I think this is hitting on a very important point about protocol transition here, something that I think all of us should step back and consider from a very humble vantage point.

The transition from IPv4 to IPv6 has been hard, certainly much harder than I think the contributors to RFC2460 originally expected. We've had to go back after the fact to define and perfect things like NAT64 to sit at the boundary of IPv6-only networks, allowing communication between IPv6-only and IPv4-only endpoints by inserting and deleting IPv6 and IPv4 headers. 

The whole idea of an extension header is to extend the capabilities of IPv6. Extended functions naturally come with transition, and transition happens progressively. Inserting and deleting an extension header is analogous to a NAT64 function - not something we necessarily want, but something we have realized we need, to handle transition within the reality that wide spread flag days are impossible.

If I take IPv6 SR as an example of an extended IPv6 function, some endpoints will support IPv6 SR sooner than others. Some network domains will operate with IPv6 SR everywhere sooner than others. The ability to classify traffic and insert an SR header upon entry into an SR domain is important to transition, and is completely analogous to what, say, T-Mobile does with NAT64 and 464xlat.  

Suresh, I think this may be a tussle point (to refer to Dave Clark's presentation earlier this evening). 2460bis should not try to over-specify here. Instead, allow for a bit of flex while we truly get our heads around how to deploy and operate systems which use IPv6 extension headers.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Mar 2017 04:38:20 -0500

> On Mar 30, 2017, at 12:09 AM, Tim Chown <[email-masked]> wrote:
> 

The same reason we have MAP-T and 464xlat. 

- Mark

---

From: "Leddy, John" <[email-masked]>
Date: Thu, 30 Mar 2017 11:06:53 +0000

The issue is the encap/decap pair - like an old circuit model.

Do we add the encap/decap function into a Domain doing native SRv6 and the complexity of choosing which to use - into all the vm's?  Or do we extend the new SRv6 domain to the legacy infrastructure.   If we do this, there is no tunnel.  There is no encap/decap pair - you need to proxy for the legacy gear/services.

John

> On Mar 30, 2017, at 4:38 AM, Mark Townsley <[email-masked]> wrote:
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 01:44:30 +1300

On 30/03/2017 15:59, Leddy, John wrote:

...
> Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking,

I've tried to say this before but I'm not sure people are getting it: 

RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others. 

There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that.

There doesn't need to be a tussle here. 

   Brian Carpenter

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 30 Mar 2017 08:11:57 -0500

Brian,

if I understand you correctly: 

If properly worded (improved) draft-voyer explicitly states – the intention is to change the 2460(bis) behavior and to allow header insertion within a controlled domain, and given there’s a valid justification of why encap wouldn’t’ meet the need, you wouldn’t oppose? 

Thanks! 

Cheers,
Jeff

On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    ...

    

       Brian Carpenter

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 30 Mar 2017 13:30:17 +0000

Hi John,
  Thanks for chiming in. I recognize that you might have use cases that might be better off with header insertion but I think they should be handled as and when they come up for consideration (e.g. in the SRv6 discussions). Holding up this document is not going to help in any way in reinterpreting what RFC2460 intended. My suggestion for proponents of safe header insertion to write up how it is expected to work and have the discussion then.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 04:11:19 +1300

> If properly worded (improved) draft-voyer explicitly states – the intention is to change the 2460(bis) behavior and to allow header insertion within a controlled domain, and given there’s a valid j…

No, I wouldn't. I might even help; hence my suggested tweak to 2460bis. Note that the tricky bit (in reality and in the text) is a crisp definition of what the domain boundary is and what happens when packets with inserted headers accidentally escape. We did hit that difficulty when trying (and failing) to define local-use rules for stateful use of the flow label. But we were trying to do that in a generic document (in effect, an extension of RFC2460) and failed for essentially the same reasons that led Suresh to his decision on 2460bis.

https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some remnants of that attempt.

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 10:31:02 -0500

Hi Brian,

Could you elaborate a bit on the definition of "accidentally escaping
packets" ?

The fundamental issue with original Suresh suggestion I see is that his
proposed text kills ability to have 2460bis as normative reference in any
other draft describing or defining extension headers. And effectively stops
any work which needs to be based on 2460bis till 2460bis is updated.

Kind regards
R.

On Mar 30, 2017 10:11, "Brian E Carpenter" <[email-masked]>
wrote:

On 31/03/2017 02:11, Jeff Tantsura wrote:
> If properly worded (improved) draft-voyer explicitly states – the
intention is to change the 2460(bis) behavior and to allow header insertion
within a controlled domain, and given there’s a valid justification of why
encap wouldn’t’ meet the need, you wouldn’t oppose?

No, I wouldn't. I might even help; hence my suggested tweak to 2460bis.
Note that the tricky bit (in reality and in the text) is a crisp definition
of what the domain boundary is and what happens when packets with inserted
headers accidentally escape. We did hit that difficulty when trying (and
failing) to define local-use rules for stateful use of the flow label. But
we were trying to do that in a generic document (in effect, an extension of
RFC2460) and failed for essentially the same reasons that led Suresh to his
decision on 2460bis.

https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some
remnants of that attempt.

    Brian

>
> Thanks!
>
> Cheers,
> Jeff
>
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <
[email-masked] on behalf of [email-masked]> wrote:
>     > If this insert/delete of an SRH is prematurely prohibited;  What is
a recommended solution to the Real World problem above.  Not use case, we
are implementing.
>     >
>     > Again; I’m worried we are eliminating a tool that may prove very
helpful, preclude its use in future IETF work and shutdown a path for
Innovation in Networking,
>     RFC2460bis, if approved as is, draws a line in the sand *for
interoperability across the whole Internet*. There are reasons for this -
PMTUD in any form, any future replacement for the unsuccessful IPsec/AH,
and all the problems of deploying extension headers that are understood by
some nodes and not by others.
>
>     There is no reason why a subsequent standards-track document cannot
allow header insertion (and removal) within finite domains where the above
issues do not apply. In fact, an improved version of
draft-voyer-6man-extension-header-insertion-00 could become exactly that.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 30 Mar 2017 15:47:22 +0000

Hi Robert,

> On Mar 30, 2017, at 10:31 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Could you elaborate a bit on the definition of "accidentally escaping packets" ?
> 
> The fundamental issue with original Suresh suggestion I see is that his proposed text kills ability to have 2460bis as normative reference in any other draft describing or defining extension headers. And effectively stops any work which needs to be based on 2460bis till 2460bis is updated.

This is not true. The *new draft* will update RFC2460bis. We do not need a new (RFC2460bis)bis to do this. I can understand that this would be bad, but that is not the intent.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 04:58:52 +1300

Hi Robert,

> Could you elaborate a bit on the definition of "accidentally escaping

There was concern that configuration errors are always possible, so a
a host might send packets with stateful flow labels to an external
destination (first error) and the border router might fail to block
them (second error). I think your case is a bit different.

(I have a meeting this afternoon with some people who want to
define a local use of flow labels compatibly with RFC6437. These
arguments span many years.)
 
> any work which needs to be based on 2460bis till 2460bis is updated.

No, that's a misunderstanding of how RFC spaghetti is constructed. What we'd
do is produce (I'm making this up) draft-ietf-6man-extension-header-insertion
which includes an Updates: 2460bis header. If approved, it becomes a Proposed
Standard that updates an Internet Standard. And it says, quite explicitly,
something like:

"Within a network domain defined as in Section N, there is an additional
exception to the following rule in Section 4 of [RFC2460bis]:
<blockquote>
   With one exception, extension headers are not examined, processed,
   inserted, or deleted 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.
</blockquote>
The exception is that..."

That's what I meant about 2460bis being a line in the *sand* in
another message. Not carved in stone.

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 11:52:41 -0500

Ok so till a new document updates 2460bis any further work on EHs is frozen
as it would reference 2460bis with new text. That was my main point.

And what current EH implementations are supposed to do in the mean time ?
Would IANA allocate codepoints for EH work before 2460bis is formally
updated which in the current IETF speed is easy 2+years ?

Note that without the proposed clarification none of the above obstacles
exist.

Thx
R.

On Mar 30, 2017 10:47, "Suresh Krishnan" <[email-masked]>
wrote:

> This is not true. The *new draft* will update RFC2460bis. We do not need a
> new (RFC2460bis)bis to do this. I can understand that this would be bad,
> but that is not the intent.
>
> Thanks
> Suresh

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 12:00:46 -0500

Michael,

Right on the spot.

SRv6 is a first serious consideration why number of enterprise networks
would benefit from and could consider IPv6 rollout.

Otherwise all discussions so far end up with "no need" as all services are
available with zoo of different protocols over v4 and amount of v4
addresses owned by given company are of no concern of depletion any time
soon.

Best,
R.

On Mar 30, 2017 11:54, "Ackermann, Michael" <[email-masked]> wrote:

This is something I tried to say at the mic today, but I was too late.
If we put potentially valuable use cases into the bucket of "Exceptions",
this becomes yet another excuse to delay or avoid adoption of IPv6 by the
very large percentage of Enterprises who have yet to do so (and have no
serious plans) today.

I am hopeful that work in the IETF will provide features and hence
motivation for us sadly delinquent Enterprises to begin actually using
IPv6.    I am concerned that perception of solutions being "Exceptions" or
non standard, will cause consternation (warranted or not) and avoidance.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, March 30, 2017 9:30 AM
To: Leddy, John <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>;
[email-masked]
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi John,
  Thanks for chiming in. I recognize that you might have use cases that
might be better off with header insertion but I think they should be
handled as and when they come up for consideration (e.g. in the SRv6
discussions). Holding up this document is not going to help in any way in
reinterpreting what RFC2460 intended. My suggestion for proponents of safe
header insertion to write up how it is expected to work and have the
discussion then.

Thanks
Suresh

>> Please feel free to comment either privately or on list if you have any
concerns with this resolution going forward.
>
>
> Suresh,
>
> I still have concerns that we are eliminating a tool that may prove very
helpful in migrations without understanding its value.
>
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has
been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to IPV6
Only, there are still many unknowns on how to complete this migration.
> The transition from Physical to Virtual Infrastructure.  Again, the
migration will be long, operationally complex and full of unexpected
challenges.
>
> In the old world with Servers running Applications in Physical locations
designed for very predictable loads; using an encap/decap tunnel to emulate
a physical circuit between locations has many attractive properties – but
that is compared to actually ordering and provisioning real circuits
between locations.
>
> In the new world of dynamic resources spun up on demand in distributed
environments across multiple providers, Applications having the
Intelligence and State to bring up their own required connectivity is very
natural.  This is where we are putting the majority of our efforts.  SRv6
enables very attractive solutions by Applications building their own
headers.
>
> The challenges come as we try to migrate and require these two
infrastructures to Interoperate for a long time.
> Supplementing the legacy infrastructure with an assist function seems
> a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap
> tunnels)
>
> The preferred assist mechanism seems to be the one that allows the New
> World to operate in its final preferred state, sending and receiving
packets with their own headers. (SRv6) But what does an Application in the
new world due when it is attempting to communicate with an Application in
the Old World?
> Shouldn’t it build an SRv6 header?  That would mean that the assist
function would need to be the last SID in the Segment List and be capable
of removing the SRH.
> Wouldn’t it make sense for the assist function to do the same thing in
the reverse direction; an Old World Server talking to a New Virtual World
Application?  Insert an SRH.
>
> If this insert/delete of an SRH is prematurely prohibited;  What is a
recommended solution to the Real World problem above.  Not use case, we are
implementing.
> Thank you for asking and listening to my concerns,

The information contained in this communication is highly confidential and
is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you are
hereby notified that any viewing, copying, disclosure or distribution of
this information is prohibited. Please notify the sender, by electronic
mail or telephone, of any unintended receipt and delete the original
message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and Blue
Shield Association.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 30 Mar 2017 16:54:36 +0000

This is something I tried to say at the mic today, but I was too late. 
If we put potentially valuable use cases into the bucket of "Exceptions",  this becomes yet another excuse to delay or avoid adoption of IPv6 by the very large percentage of Enterprises who have yet to do so (and have no serious plans) today. 

I am hopeful that work in the IETF will provide features and hence motivation for us sadly delinquent Enterprises to begin actually using IPv6.    I am concerned that perception of solutions being "Exceptions" or non standard, will cause consternation (warranted or not) and avoidance. 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, March 30, 2017 9:30 AM
To: Leddy, John <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>; [email-masked]
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi John,

Thanks
Suresh

> World to operate in its final preferred state, sending and receiving packets with their own headers. (SRv6) But what does an Application in the new world due when it is attempting to communicate with an Application in the Old World?

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 30 Mar 2017 11:19:28 -0700

At Thu, 30 Mar 2017 11:52:41 -0500,

> as it would reference 2460bis with new text. That was my main point.

I don't get the logic...an "update" can start immediately once such a
draft new proposal is available.  The update won't be formally
completed until it gets some formal state like a standard track RFC,
and it will take time, but that wouldn't necessarily mean a further
work is "frozen"; it's not very clear to me what this term means in
this context, but it's quite common development takes place while the
spec is being discussed as a draft, and it's also not uncommon some
commercial operators even start deploying it.  On the other hand, even
if we now agreed that rfc2460bis should explicitly allow such "further
work", the discussion itself would take long and wouldn't be completed
soon.

But IMO it's irresponsible to leave the text ambiguous and let some
other people misunderstand it, possibly even more casually and/or in
the global Internet, for the comfort of some particular future work.
I think we're now trying to help avoid the latest clarification in
rfc2460bis to be interpreted as an "outright ban" of future updates
while still trying to be responsible for the soundness of the global
Internet.  In my understanding Brian's additional text is one such
attempt (I also proposed text in that sense at the time of WGLC,
although it wasn't adopted in the end).  If that text is still not
enough we can discuss how to phrase it.  And, while I suspect people
who wanted to keep the ambiguity will never be satisfied with the
result as long as the added clarification remains, I believe that's a
reasonable compromise to achieve a balance between being responsible
and not (unintentionally) discouraging future updates.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 07:52:44 +1300

On 31/03/2017 07:19, 神明達哉 wrote:
> work is "frozen"; 

Exactly. At this time the *quickest* way forward is to get 2460bis through
the IESG, progress the -extension-header-insertion draft ASAP, and in due
time do an early assignment request for draft-ietf-6man-segment-routing-header

If you try that early assignment request today, it seems likely to fail.

   Brian

> it's not very clear to me what this term means in

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 20:25:56 +0100

Hi,

> On 30 Mar 2017, at 19:19, 神明達哉 <[email-masked]> wrote:
> 

Repeating what I said at the mic, my views echo those of Jinmei, Michael, Lorenzo and Brian. I agree with the decision to progress RFC2460-bis to IS including Suresh’s text. I’d also like to see Brian’s short amendment included, which makes explicit Internet scope as the default target.

Advancing 2460bis doesn’t freeze work on SR; that work can continue today. I don’t see the new SR header insertion draft completing in “a couple of weeks”; it’s much more likely to take several months or even a year to progress through WG adoption and eventual publication, to ensure good and robust input. For adoption, I’d expect many people to want the draft to include text on a) why vanilla encapsulation is not sufficient and b) how the insertion can guaranteed to be done safely for specific scenario(s). But that’s all very possible.

And please do note that publishing 2460-bis as an Internet Standard does not set it in stone. Your SR work can update it, as could other future RFC(s) on other new mechanism(s) or innovation(s) that have yet to be proposed. I’d argue that it’s pretty likely we’ll see other RFCs update 2460-bis; that shouldn’t be a surprise if it’s a protocol that we’ll be using for the next 20-30 years or more. For each, we’ll just see “Updated by:” tags in the RFC header. The current RFC2460 has accumulated nine such tags in 19 years, so about one every two years.

On enterprise deployment I’d argue that, if anything, moving to IS should help strengthen the case for deployment, because it confirms proven widescale deployment.  The four criteria for moving to IS are described in Section 2.2 of RFC6410, but are summarised as "a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community”. I’d hope we have very strong consensus on that statement.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 19:27:15 +0000

Hi,

Tim

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 Mar 2017 07:24:16 +1100

The thing to keep in mind is that enterprises use technology to solve
business problems. Technology is a means to an end, not the end
itself.

For general Internet or internal networking problems, IPv6 doesn't
solve the problem any better than IPv4 does. That is why Enterprises
haven't adopted it for their Internet or general internal networks.
Adding IPv6 is actually worse - it just increases their capex and opex
for no business benefit.

I've heard SR recently called the next MPLS. So how many Enterprises
have adopted MPLS?

When Enterprises need to access IPv6 Internet services, they'll just
IPv6 enable their boundary Internet access security devices and mail
servers.

IPv6 will be used by Enterprises when it either provides a compelling
advantage over IPv4, or where a vendor's "turn key" solution uses it.
I've seen that recently with AMI smartmeter mesh networks.

Here in Victoria, AU, there are probably in the order of 1M+ IPv6 AMI
smart meters across multiple electricity distributors. They're using
IPv6 for that because that is what the vendor's end-to-end AMI
solution uses. They use IPv4 to access the OSS and servers that are
used to troubleshoot that network, and there is no real benefit for
the organisation to deploy IPv6 on their internal LANs to access those
servers.

Inventing a new IPv6 feature just to try to encourage adoption isn't
going to be that successful. The new feature has to be a compelling
solution to a problem that the enterprise has, that justifies the
additional and typically very large expense of deploying IPv6 to get
it.

Regards,
Mark.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 30 Mar 2017 20:20:46 +0000

Great thoughts/info and they all make sense from an IETF perspective. 
From an enterprise perspective, it is unlikely that anyone in that world knows what moving to IS means or implies.   
So the problem that I have in trying to get my enterprise, or the many we have direct (or even indirect) connections with, to even THINK about IPv6, is coming up with reasons to do so.   There are a couple of reasons/features that I have hope could be compelling.  But if those features depend on EHs, or anything unsupported, future or "Exceptional",  they will not be compelling at all.  
My world is a tough sell.   I just do not want it to get any tougher.  
Thanks
Mike

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Thursday, March 30, 2017 3:27 PM
To: 6man WG <[email-masked]>; [email-masked]
Cc: IETF Discussion <[email-masked]>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi,

>> Ok so till a new document updates 2460bis any further work on EHs is 
>> frozen as it would reference 2460bis with new text. That was my main point.
> 

Tim

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 15:44:59 -0500

Hi Mark,

And this is precisely what we are saying.

Enterprise I work for has global L3VPN network with MPLS, LDP, 3107 across
3 ASes spanning the globe. Obviously with that you also need various
InterAS options.

On top of that there is some limited need for inter-as TE so you employ
static EROs and RSVP-TE.

We have need to do efficient p2mp data distribution in WAN which again
requires another set of different protocols.

Imagine opex with all of the above.

And at this time SRv6 delivers all of the above applications with huge
reduction of need of various protocols mentioned above.

That was the point.

Cheers,
R.

On Mar 30, 2017 15:24, "Mark Smith" <[email-masked]> wrote:

> > If we put potentially valuable use cases into the bucket of
> "Exceptions",  this becomes yet another excuse to delay or avoid adoption
> of IPv6 by the very large percentage of Enterprises who have yet to do so
> (and have no serious plans) today.
> >
> >>> Please feel free to comment either privately or on list if you have
> any concerns with this resolution going forward.
> >>
> >>
> >> Suresh,
> >>
> >> I still have concerns that we are eliminating a tool that may prove
> very helpful in migrations without understanding its value.
> >>
> >> As we contemplate finishing this major Network shift – We find
> ourselves in the early stages of another.
> >>
> >> In the old world with Servers running Applications in Physical
> locations designed for very predictable loads; using an encap/decap tunnel
> to emulate a physical circuit between locations has many attractive
> properties – but that is compared to actually ordering and provisioning
> real circuits between locations.
> >>
> > The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross and
> Blue Shield Association.

---

From: [email-masked]
Date: Thu, 30 Mar 2017 15:48:33 -0500

Robert,

> Ok so till a new document updates 2460bis any further work on EHs is frozen as it would reference 2460bis with new text. That was my main point.
> 
> And what current EH implementations are supposed to do in the mean time ? Would IANA allocate codepoints for EH work before 2460bis is formally updated which in the current IETF speed is easy 2+years ?
> 
> Note that without the proposed clarification none of the above obstacles exist.

Write a document describing the mechanism using header insertion. That document should cover the issues raised with header insertion in general. I don't think the document should update 2460bis. The general restriction still stands.

Best regards,
Ole

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 15:55:23 -0500

Ole,

Correct me if I am missing someting but the entire debate is not about
describing or not header insertion.

I am under assumption that originating hosts still can legally insert it.

It is all about to modify EH in flight - right ? Moreover concerns raised
are about side effects of it like MTU .. not lack of instructions on how to
insert, modify or remove EH elements.

So what exactly are you expecting WG to deliver as next step if 2460bis
goes fwd ? Is detecting the max MTU on end to end path even in 6man's
charter ?

Cheers,
R.

On Mar 30, 2017 15:48, <[email-masked]> wrote:

> > And what current EH implementations are supposed to do in the mean time
> ? Would IANA allocate codepoints for EH work before 2460bis is formally
> Write a document describing the mechanism using header insertion. That
> document should cover the issues raised with header insertion in general. I
> don't think the document should update 2460bis. The general restriction
> still stands.
>
> Best regards,
> Ole
>

---

From: [email-masked]
Date: Thu, 30 Mar 2017 16:05:33 -0500

Robert,

> Correct me if I am missing someting but the entire debate is not about describing or not header insertion.
> 
> It is all about to modify EH in flight - right ? Moreover concerns raised are about side effects of it like MTU .. not lack of instructions on how to insert, modify or remove EH elements.
> 
> So what exactly are you expecting WG to deliver as next step if 2460bis goes fwd ? Is detecting the max MTU on end to end path even in 6man's charter ?

You can write a new protocol specification independently of 2460bis that does whatever it has to do, and then we can argue over that document on its own merits.

Cheers,
Ole

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Mar 2017 16:13:03 -0500

What's wrong or what is missing in
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05

?

On Mar 30, 2017 16:05, <[email-masked]> wrote:

> > It is all about to modify EH in flight - right ? Moreover concerns
> raised are about side effects of it like MTU .. not lack of instructions on
> how to insert, modify or remove EH elements.
> >
> You can write a new protocol specification independently of 2460bis that
> does whatever it has to do, and then we can argue over that document on its
> own merits.
>
> Cheers,
> Ole
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 10:50:29 +1300

> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05

Once we get 2460bis out of the door, we should seriously tackle that question.
Honestly it's going to be easier then. I perhaps disagree with Ole whether we
need an Updates: 2460bis but that depends on the details.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 21:59:18 +0000

> On 30 Mar 2017, at 22:50, Brian E Carpenter <[email-masked]> wrote:
> 

Agreed (on both points). And I think you’ll find many who want 2460bis to ship as proposed by our AD will also be very willing to help work through the issues. 

Tim

---

From: Jen Linkova <[email-masked]>
Date: Fri, 31 Mar 2017 00:13:44 +0200

>  the case of multicast) identified in the Destination Address field of

I have some concerns with how that sentence AND the following note
comes together:

"  With one exception, extension headers are not examined, processed,
   inserted, or deleted 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.  Note: If an intermediate forwarding node examines
   an extension header for any reason, it must do so in accordance with
   the provisions of [RFC7045].  "

I'm afraid that the lack of the normative language strikes back..
If 'are not examined" is to be interpreted as RFC2119 'MUST NOT',
then the following note conflicts with that statement. 'A node MUST
NOT examine EHs
but if it does it must do it as per RFC7045' - it is extremely controversial.

If ''are not examined" is to be read as RFC2119 'SHOULD NOT' then I
have a very good news for
those who would still like to insert/delete EHs: they can do it  as
long as  they have
"valid reasons in particular circumstances when the particular
behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.".
But from today's presentation I've got an impression that the
intention of this text was actually to prohibit EH insertion
(the sildes say 'no one argued against the fact that the intent of the
text in RFC2460
was to forbid insertion of extension headers on any other node but the source
of the packet.).

So to summarize: the proposed text either explicitly prohibits the
examination (and then it contradicts the next sentence and we need to
do smth with the note and RFC7045) OR it allows EH insertion - it
depends how the text is interpreted.

-- 
SY, Jen Linkova aka Furry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 12:09:06 +1300

On 31/03/2017 11:13, Jen Linkova wrote:
>> Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.  The only argument ma
>  de against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change.
>>
>> OLD (from -08):
>>

Exactly the opposite, IMHO. I think it's much better like this than it
would be under RFC2119 (although in fact that doesn't change the 
English meaning of 'must'). The "Note:" describes a situation where
middleboxes are actually breaking the rule. We had that fight before
RFC7045.

     Brian

---

From: Jen Linkova <[email-masked]>
Date: Fri, 31 Mar 2017 01:53:03 +0200

> middleboxes are actually breaking the rule. We had that fight before

Shell we then say
'Extension headers are not processed by intermediate nodes unless
those nodes strictly
follow [RFC7045].  With one exception, extension headers are not modified,
inserted, or deleted 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."
?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Mar 2017 09:11:45 -0500

I do not understand how 2460bis makes it "easier" if proposed change to the
text directly tries to prohibit what is described in a document already
long time back accepted as a 6man working group draft.

That's to the best of my memory an IETF precedent.

Cheers,
R.

On Mar 30, 2017 16:50, "Brian E Carpenter" <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05

Once we get 2460bis out of the door, we should seriously tackle that
question.
Honestly it's going to be easier then. I perhaps disagree with Ole whether
we
need an Updates: 2460bis but that depends on the details.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 31 Mar 2017 14:38:40 +0000

On 31 Mar 2017, at 00:09, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

On 31/03/2017 11:13, Jen Linkova wrote:
On Wed, Mar 15, 2017 at 3:47 AM, Suresh Krishnan
<[email-masked]<mailto:[email-masked]>> wrote:
Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.  The only argument m
a
de against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change.

OLD (from -08):

NEW:

Indeed. The RFC7045 exception applies specifically to *examining* headers, with the common use case being firewalling.

Changing the RFC7045 exception text to clarify this in 2460bis was proposed, but it wasn’t taken forward.

Tim

    Brian

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

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 31 Mar 2017 15:04:05 +0000

QUESTION:
Does the word PROCESSED, mean change, implying write capability?
If yes, can that be stated?

From: ipv6 [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Friday, March 31, 2017 10:39 AM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

OLD (from -08):

NEW:

Tim

    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 31 Mar 2017 15:32:13 +0000

Hi Robert,

> On Mar 31, 2017, at 9:11 AM, Robert Raszuk <[email-masked]> wrote:
> 
> I do not understand how 2460bis makes it "easier" if proposed change to the text directly tries to prohibit what is described in a document already long time back accepted as a 6man working group draft.

First of all, adopting something as a working group document only means that it is a starting point. Adoption of a document does not mean that there is WG agrees with all the text in the document. That is why the document goes under WG change control.
Secondly, I have no idea what you are talking about in this specific case. What work in 

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06>

do you think is prohibited by this text? Can please provide a text quote from the draft?

Thanks
Suresh

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Mar 2017 12:01:17 -0500

Hi Suresh,

As you requested one of many quotes from the draft which your clarification
to 2460bis directly contradicts with:

This include either:

      A host originating an IPv6 packet.

      *An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.*

Cheers,
R.

On Mar 31, 2017 10:32, "Suresh Krishnan" <[email-masked]>
wrote:

> I do not understand how 2460bis makes it "easier" if proposed change to
> the text directly tries to prohibit what is described in a document already
> First of all, adopting something as a working group document only means
> that it is a starting point. Adoption of a document does not mean that
> there is WG agrees with all the text in the document. That is why the
> document goes under WG change control.
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 31 Mar 2017 17:46:43 +0000

Hi Robert,

> On Mar 31, 2017, at 12:01 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Suresh,
> 
> As you requested one of many quotes from the draft which your clarification to 2460bis directly contradicts with:
> 
> This include either:
> 
>       An SR domain ingress router encapsulating a received IPv6 packet
>       into an outer IPv6 header followed by an SRH.

Excellent. Thanks for pointing out the exact text. I can confirm that this text  *is compliant* with the RFC2460bis text.

Thanks
Suresh

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Mar 2017 12:56:24 -0500

Even if we treat encapsulation in new IPv6 header as only an option ?

Thx
R.

On Mar 31, 2017 12:46, "Suresh Krishnan" <[email-masked]>
wrote:

> As you requested one of many quotes from the draft which your
> clarification to 2460bis directly contradicts with:
>
> This include either:
>
> Excellent. Thanks for pointing out the exact text. I can confirm that this
> text  *is compliant* with the RFC2460bis text.
>
> Thanks
> Suresh
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 31 Mar 2017 18:08:22 +0000

Hi Robert,

> On Mar 31, 2017, at 12:56 PM, Robert Raszuk <[email-masked]> wrote:
> 

There are two options listed in the draft with the “either” clause quoted below. Both of them are compliant. In fact, in my not so careful reading, I do not see any text in draft-ietf-6man-segment-routing-header-06 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that would be contrary to this text in RFC2460bis.

Thanks
Suresh

P.S.: I am assuming you are using the word option to mean a choice and not an IPv6 option. If not, please clarify.

> 
> Thx
> R.
> 
> 
> 
> On Mar 31, 2017 12:46, "Suresh Krishnan" <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Robert,
> 
>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Suresh,
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 31 Mar 2017 13:14:06 -0500

Hi Suresh,

The fact that encapsulation in new v6 header is optional to me is clearly
stated in section 4.1 of that document:

 By default, a local SID bound to the End function does not allow
      the decapsulation of an outer header.  As a consequence, an End
      SID cannot be the last SID of an SRH and cannot be the DA of a
      packet without SRH.

   o  If the decapsulation is desired, then another function must be
      bound to the SID (e.g., End.DX6 defined in
      [I-D.filsfils-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.filsfils-spring-srv6-network-programming>]).
This prevents
      any unintentional decapsulation by the segment endpoint node.  The
      details of the advertisement of a SID in the control plane are
      outside the scope of this document (e.g.,
      [I-D.previdi-idr-segment-routing-te-policy
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.previdi-idr-segment-routing-te-policy>],
      [I-D.dawra-bgp-srv6-vpn
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.dawra-bgp-srv6-vpn>]
and [I-D.bashandy-isis-srv6-extensions
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.bashandy-isis-srv6-extensions>].

On Mar 31, 2017 13:08, "Suresh Krishnan" <[email-masked]>
wrote:

> There are two options listed in the draft with the “either” clause quoted
> below. Both of them are compliant. In fact, in my not so careful reading, I
> do not see any text in draft-ietf-6man-segment-routing-header-06
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that
> would be contrary to this text in RFC2460bis.
>
> Thanks
> Suresh
>
>> Excellent. Thanks for pointing out the exact text. I can confirm that
>> this text  *is compliant* with the RFC2460bis text.
>>
>> Thanks
>> Suresh
>>
>>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 07:18:54 +1300

Robert,

Actually this was thoroughly discussed (mainly with Stefano I think)
and these texts in draft-ietf-6man-segment-routing-header-06 were
carefully designed to be compatible with both RFC2460 and RFC2460bis:

Section 2.3.1:
>  The outer header with the SRH is no different from any other
>  tunneling encapsulation mechanism and allows a network operator to
>  implement traffic engineering mechanisms so to efficiently steer
>  traffic across his infrastructure.
 
Section 5.1:
>  A Source SR Node can be any node originating an IPv6 packet with its
>  IPv6 and Segment Routing Headers.  This include either:
> 

I suppose we need expert review of the routing header itself, but
for me there is simply no issue about compatibility with 2460(bis).

(draft-voyer-6man-extension-header-insertion is a quite different
conversation and we should not confuse the two. That would be FUD.)

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 07:35:34 +1300

On 01/04/2017 07:14, Robert Raszuk wrote:
>       bound to the SID 

Sure, any tunnel needs a decapsulator as well as an encapsulator. That's
not news, so what is the problem here? I assume you'd decapsulate in
the last hop router. I don't claim to understand segment routing, so
I can't actually understand the above text. But the text elsewhere
is clear enough that either the original source or the encapsulator
builds the routing header, and that's all we need to know for
2460(bis) compatibility. So why are we still discussing?

    Brian

> (e.g., End.DX6 defined in

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 07:42:58 +1300

> If yes, can that be stated?

I believe we went around that some time back and settled on 'processed'
as covering both calculating and modifying. I'm not enthusiastic
to wordsmith this yet again, personally, IMHO, YMMV. We've already
had to wordsmith the 'examined'.

    Brian

---

From: [email-masked] (Martin Rex)
Date: Fri, 31 Mar 2017 21:27:27 +0200 (CEST)

> would benefit from and could consider IPv6 rollout.

Are you "back from the future" and accidentally confusing dreams with
what is currently available?  ;-)

https://www.theregister.co.uk/2017/01/19/windows_10_bug_undercuts_ipv6_rollout/

  "The horrible irony of Microsoft waiting on its own team to fix
   a networking bug aside, the post goes some way to highlighting
   why it is that IPv6 is still not widely available: because it's a mess."

-Martin