Subject: Proposed revised Extension Header text for rfc2460bis

From: Bob Hinden <[email-masked]>
Date: Mon, 24 Apr 2017 15:52:47 -0700

Hi,

After reading through the discussion about this text in Section 4, I have some new text to propose.  I think this is significantly improved and should resolve many of the issued raised.

Changes include separate description of behaviors extension headers and the hop-by-hop option header, remove “examine” from the first paragraph.  I removed “examine” because I am convinced it’s not sustainable to say a node can’t examine extension given how widespread this behavior is.  I also removed the reference to RFC7045 because examine is removed.  RFC7045 is referenced in the recently updated Security Considerations section.

I removed the “including the source and destination nodes” text from the paragraph on the hop-by-hop options header because I don’t think we need to mention the source, and there is a whole paragraph describe what happens at the destination node.  I also added the text about from the first paragraph about reaching the destination to the hop-by-hop header paragraph.

I also moved (without change) the “At the Destination node...” text from the first paragraph to a new third paragraph.  It applies to all extension headers.

CURRENT and NEW text below.  Please review and comment.

Bob

   CURRENT

   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].  At the Destination node, normal
   demultiplexing on the Next Header field of the IPv6 header invokes
   the module to process the first extension header, or the upper-layer
   header if no extension header is present.  The contents and semantics
   of each extension header determine whether or not to proceed to the
   next header.  Therefore, extension headers must be processed strictly
   in the order they appear in the packet; a receiver must not, for
   example, scan through a packet looking for a particular kind of
   extension header and process that header prior to processing all
   preceding ones.

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that may be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

   NEW

   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 (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined and processed by every 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.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

   At the Destination node, normal demultiplexing on the Next Header
   field of the IPv6 header invokes the module to process the first
   extension header, or the upper-layer header if no extension header is
   present.  The contents and semantics of each extension header
   determine whether or not to proceed to the next header.  Therefore,
   extension headers must be processed strictly in the order they appear
   in the packet; a receiver must not, for example, scan through a
   packet looking for a particular kind of extension header and process
   that header prior to processing all preceding ones.

   END NEW

---

From: Tom Herbert <[email-masked]>
Date: Mon, 24 Apr 2017 16:16:00 -0700

>    examined and processed by every node along a packet's delivery path,

Hi Bob,

I would suggest this to substitute "any" for "every"  and "and" for "or" to get:

"The Hop-by-Hop Options header is not inserted or deleted, but may be
examined or processed by any node along a packet's delivery path,"

Tom

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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 24 Apr 2017 16:19:22 -0700

Tom,

> On Apr 24, 2017, at 4:16 PM, Tom Herbert <[email-masked]> wrote:
> 
> examined or processed by any node along a packet's delivery path,”

I agree, that is better.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Apr 2017 11:22:34 +1200

This works for me and seems to combine the WG rough consensus with the IESG comments.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Apr 2017 20:19:11 +1000

I'm happy with it too, and agree that Tom's suggested changes make it
better.

Regards,
Mark.

On 25 Apr. 2017 09:22, "Brian E Carpenter" <[email-masked]>
wrote:

This works for me and seems to combine the WG rough consensus with the IESG
comments.

Regards
   Brian Carpenter

On 25/04/2017 10:52, Bob Hinden wrote:
> Hi,
>
> After reading through the discussion about this text in Section 4, I have
some new text to propose.  I think this is significantly improved and
should resolve many of the issued raised.
>
> Changes include separate description of behaviors extension headers and
the hop-by-hop option header, remove “examine” from the first paragraph.  I
removed “examine” because I am convinced it’s not sustainable to say a node
can’t examine extension given how widespread this behavior is.  I also
removed the reference to RFC7045 because examine is removed.  RFC7045 is
referenced in the recently updated Security Considerations section.
>
> I removed the “including the source and destination nodes” text from the
paragraph on the hop-by-hop options header because I don’t think we need to
mention the source, and there is a whole paragraph describe what happens at
the destination node.  I also added the text about from the first paragraph
about reaching the destination to the hop-by-hop header paragraph.
>
> I also moved (without change) the “At the Destination node...” text from
the first paragraph to a new third paragraph.  It applies to all extension
headers.

---

From: Tim Chown <[email-masked]>
Date: Wed, 26 Apr 2017 13:37:56 +0000

Hi,

I agree this text is much better. Just a couple of minor comments below.

> On 24 Apr 2017, at 23:52, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 

Actually, if we are rewriting this anyway, the multicast wording should probably say “(or, in the case of multicast, any node in the multicast group)”, else we’re suggesting actions cannot be taken until each receiver has received its copy.  

>   examined and processed by every node along a packet's delivery path

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

The same comment again for multicast.

>   that header prior to processing all preceding ones.

There is also the NOTE: text to place:

   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so.

This might fit better after the HbH paragraph above, rather than (as it would be now) after the Destination node paragraph?

Tim

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Apr 2017 08:40:03 -0700

Hi Tim,

> On Apr 26, 2017, at 6:37 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

Thanks

> Actually, if we are rewriting this anyway, the multicast wording should probably say “(or, in the case of multicast, any node in the multicast group)”, else we’re suggesting actions cannot be taken…

I went back and looked at the previous RFCs.  In both RFC2460 and RFC1883, say:

  (or each of the set of nodes, in the case of multicast)

So this text has been there a while and I don’t think it has caused confusion.  I understand you point, but think saying “each” makes it clear.  For example it doesn’t say “all nodes in the case of multicast”.  It would also be close to impossible to implement “until each receiver has received its copy”.

My preference is to not change it.

> This might fit better after the HbH paragraph above, rather than (as it would be now) after the Destination node paragraph?

I had planned to leave it following, but I agree it would be better after the HbH paragraph.

Thanks,
Bob

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 27 Apr 2017 12:04:29 +0000

> On Apr 25, 2017, at 12:52 AM, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 

my recommendation is to change “are not” with “SHOULD NOT”.

This doesn’t change what the current text assumes while it uses a more formal language.

s.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 27 Apr 2017 12:58:40 -0700

Agreed

rfc2119 has clear definition of the normative language that alleviates 
any ambiguity. So it is always good to use them

Ahmed

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Apr 2017 08:54:27 +1200

> any ambiguity. So it is always good to use them

iirc the WG already agreed to the editor's choice to follow RFC2460 by using
plain English rather than RFC2119. And "are not" does not mean the same thing
as "should not", with or without upper case letters. Personally, I agree with
"are not" and disagree with "should not", which changes the meaning.

   Brian

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Fri, 28 Apr 2017 07:47:41 -0700

If I were to implement this RFC, what is the meaning of "are not"? where 
is unambiguously defined?

Ahmed

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Apr 2017 17:04:31 +0100

>> On Apr 25, 2017, at 12:52 AM, Bob Hinden <[email-masked]>
[....]
> This doesn’t change what the current text assumes while it uses a

This would be incorrect. "are not" is similar to "must not", whereas
"should not" is not. And what the wg meant is "MUST NOT". If there s any
change to be made, it is to replace "are not" with "must not".

And we should probably do, so that we can avoid the next 100+ message
debate on "what 'are not' means".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Apr 2017 17:06:31 +0100

> "are not" and disagree with "should not", which changes the meaning.

FWIW, I agree 100% with you.

That said, given the past (unfortunate) history with this topic, we
should probably change the "are not" to "must not", so that we can avoid
future debates on what "are not" means (clearly, it means "must not").

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Apr 2017 17:07:39 +0100

Abmed,

What I was thought when learning English as a second language is that
"are not" has the same meaning as "must not".

Thanks,
Fernando

On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:
>>>>> After reading through the discussion about this text in Section 4,
>>>>> I have some new text to propose.  I think this is significantly
>>>>> improved and should resolve many of the issued raised.
>>>>>
>>>>> Changes include separate description of behaviors extension headers
>>>>> and the hop-by-hop option header, remove “examine” from the first
>>>>> paragraph.  I removed “examine” because I am convinced it’s not
>>>>> sustainable to say a node can’t examine extension given how
>>>>> widespread this behavior is.  I also removed the reference to
>>>>> RFC7045 because examine is removed.  RFC7045 is referenced in the
>>>>> recently updated Security Considerations section.
>>>>>
>>>>> I removed the “including the source and destination nodes” text
>>>>> from the paragraph on the hop-by-hop options header because I don’t
>>>>> think we need to mention the source, and there is a whole paragraph
>>>>> describe what happens at the destination node.  I also added the
>>>>> text about from the first paragraph about reaching the destination
>>>>> to the hop-by-hop header paragraph.
>>>>>
>>>>> I also moved (without change) the “At the Destination node...” text
>>>>> from the first paragraph to a new third paragraph.  It applies to
>>>>> all extension headers.
>>>>>

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Fri, 28 Apr 2017 16:12:25 +0000

So why not use the standardized "must not"?

Ahmed

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Friday, April 28, 2017 9:08 AM
To: Ahmed Bashandy (bashandy); Brian E Carpenter; Stefano Previdi (sprevidi); Bob Hinden
Cc: IPv6 List
Subject: Re: Proposed revised Extension Header text for rfc2460bis

Abmed,

What I was thought when learning English as a second language is that "are not" has the same meaning as "must not".

Thanks,
Fernando

On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:
> If I were to implement this RFC, what is the meaning of "are not"? 
> where is unambiguously defined?
> 
> Ahmed
> 
>>> rfc2119 has clear definition of the normative language that 
>>> alleviates any ambiguity. So it is always good to use them
>> iirc the WG already agreed to the editor's choice to follow RFC2460 
>> by using plain English rather than RFC2119. And "are not" does not 
>> mean the same thing as "should not", with or without upper case 
>> letters. Personally, I agree with "are not" and disagree with "should 
>> not", which changes the meaning.
>>
>>     Brian
>>
>>> Ahmed
>>>
>>>
>>>>> Changes include separate description of behaviors extension 
>>>>> headers and the hop-by-hop option header, remove “examine” from 
>>>>> the first paragraph.  I removed “examine” because I am convinced 
>>>>> it’s not sustainable to say a node can’t examine extension given 
>>>>> how widespread this behavior is.  I also removed the reference to
>>>>> from the paragraph on the hop-by-hop options header because I 
>>>>> don’t think we need to mention the source, and there is a whole 
>>>>> paragraph describe what happens at the destination node.  I also 
>>>>> added the text about from the first paragraph about reaching the 
>>>>> destination to the hop-by-hop header paragraph.
>>>>>
>>>>> I also moved (without change) the “At the Destination node...” 
>>>>> text from the first paragraph to a new third paragraph.  It 
>>>>> applies to all extension headers.
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -- IETF IPv6 working group mailing list [email-masked] 
>>>>> Administrative Requests: 
>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>> -------------------------------------------------------------------
>>>> - IETF IPv6 working group mailing list [email-masked] Administrative 
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Fri, 28 Apr 2017 09:18:44 -0700

I also agree
Using the standardized keywords avoids any *language-dependent* 
misunderstandings

Going back to the original discussion, I agree with Stefano's "should 
not" in this place

Ahmed

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 28 Apr 2017 17:18:48 +0100

> future debates on what "are not" means (clearly, it means "must not").

Perhaps change to rfc6919-style "MUST NOT(BUT WE KNOW YOU WILL)"

Nick

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Apr 2017 10:22:01 -0700

At Fri, 28 Apr 2017 09:18:44 -0700,

> Using the standardized keywords avoids any *language-dependent*

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.

> Going back to the original discussion, I agree with Stefano's "should

I don't agree "should not" is an appropriate replacement of "are not",
just like Brian and Fernando.  I also agree with Fernando in that it's
actually much closer to "must not", if anything.  So if our goal is to
make it clearer, the logical conclusion should be a "must not".  But,
I personally would like to suggest stopping wording nitpicking like
this one.  I understand some people are not happy about the sense of
the wording.  In fact, I suspect we have this discussion not because
it's unclear or informal but because the meaning is closer to "must
not" and not all people like it.  But IMO at this stage it's much more
productive if we focus on shipping rfc2460bis and discussing other
updates to it sooner.

So I support the word "are not" and finishing the task.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Apr 2017 08:16:31 +1200

> future debates on what "are not" means (clearly, it means "must not").

Exactly. On the other hand, we are an international community so any time
anybody sees ambiguity, it is good to clarify it.

   Brian

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Apr 2017 19:47:47 -0400

"Are not" is present tense while "must not" is future tense.

So this entire debate here is like defining the global speed limit in one
law for all care makers to never exceed 100 just to immediately after
promise to start working on new regulation which tries to relax this and
allow to drive 200+ on selected roads.

Except that cars can drive on all roads ...

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Apr 2017 16:57:42 -0700

> On Apr 28, 2017, at 4:47 PM, Robert Raszuk <[email-masked]> wrote:
> 

You might be interested in the comment in https://www.usingenglish.com/forum/threads/136704-Past-and-future-tense-of-must. "Must" has no past, and no future, tense, per this conversation. 

> So this entire debate here is like defining the global speed limit in one law for all care makers to never exceed 100 just to immediately after promise to start working on new regulation which tries to relax this and allow to drive 200+ on selected roads. 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Apr 2017 21:15:20 -0400

Hi Robert,

On Apr 28, 2017 7:50 PM, "Robert Raszuk" <[email-masked]> wrote:

Personally, I am perfectly fine with the text staying as "are not". "must
not" was a suggestion upthread from Ahmed, Fernando, and Jinmei.

I think this analogy is not fitting. We are not talking about speeds or
magnitude here. This case is more like: There are billion cars on the roads
today that have drivers. You can drive a car on these roads without a
driver when you can prove your autonomous car is safe.

Thanks
Suresh

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Apr 2017 21:35:58 -0400

Hi Suresh,

I am not quite seeing your comparison as well I admit maybe my analogy wad
not that perfect too in describing the situation.

Let me try again ...

Yes there are billions of cars on the roads today. However this debate is
not about putting them into any risk of collisions with those new ones.

Instead we are talking about adding a gps to selected drivers which can
influence directing cars left or right and what is even more significant
only at selected and upgraded intersections (read dst address in ipv6 top
header only) .

I truly do not understand this entire resistance from innovation. Perhaps
the crux of it is that it is misunderstood by number of folks or that most
folks just did not have time to understand last few years of segment
routing work.

Adding overpass or underpass at specific intersections to subset of cars is
in no way to cause any danger to existing traffic.

No one here will or even can to ask for special handling of cars on non
upgraded yet intersections to support it.

Cheers,
R.

On Apr 28, 2017 21:15, "Suresh Krishnan" <[email-masked]> wrote:

Hi Robert,

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Apr 2017 14:57:56 +1200

Robert,

...
> I truly do not understand this entire resistance from innovation.

There isn't. Once again: when we have 2460bis approved for full Internet
Standard, thus defining Internet-wide interoperability, we can start a serious
discussion of next steps for domain-local extensibility. I'll be happy to
help improve draft-voyer-6man-extension-header-insertion, or whatever else
seems like the best way forward.

It isn't as if we have no domain-local features already; diffserv is
defined as domain-local and so of course are ULAs.

     Brian

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Apr 2017 06:28:03 -0400

The point is that SRv6 with SRH actions to me should be full internet-wide
standard and not domain-local one.

//R.

PS. Just look at current proprietary SD-WANs or interoperable IETF LISP.
They are all - by design - Internet wide. So it is in general possible to
innovate at Internet scale. Why revised in 2017 rfc2460 just does not
accomodate the current needs and latest developments i IPv6 space ?

On Apr 28, 2017 23:00, "Brian E Carpenter" <[email-masked]>
wrote:

Robert,

...

Standard, thus defining Internet-wide interoperability, we can start a
serious

     Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Sat, 29 Apr 2017 20:45:35 +0000

> On Apr 28, 2017, at 6:18 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Fernando Gont wrote:
> Perhaps change to rfc6919-style "MUST NOT(BUT WE KNOW YOU WILL)”

I’d support that text ;-)

s.

---

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

> On Apr 28, 2017, at 7:22 PM, 神明達哉 <[email-masked]> wrote:
> 

why not ? 

isn’t the point of a normative document to use normative language ? 

> 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.

> actually much closer to "must not", if anything.

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

s.

>  So if our goal is to

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 29 Apr 2017 22:55:49 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of Robert Raszuk

> PS. Just look at current proprietary SD-WANs or interoperable IETF
> LISP. They are all - by design - Internet wide. So it is in general
> possible to innovate at Internet scale. Why revised in 2017 rfc2460
> just does not accomodate the current needs and latest developments
> i IPv6 space ?

The general feeling has been expressed many times. Go ahead and innovate, but not by violating certain fundamental rules, established way back when. People count on those rules remaining in place. By violating them, you will break things that work just fine now.

So innovate without violating basic rules, on the open Internet. Or violate the rules all you like, but make sure it is only among "consenting adults," which means, in a local domain. It's always been this way, so this should not come as a surprise?

Bert

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Apr 2017 21:45:45 -0400

So innovate without violating basic rules, on the open Internet. Or violate
the rules all you like, but make sure it is only among "consenting adults,"
which means, in a local domain. It's always been this way, so this should
not come as a surprise?

Bert

Dear Bert,

To your quote "It's always been this way" I completely and respectfully
disagree.

If the IETF would be stuck in not violating on what you call "basic rules"
we would still be classfull and never use CIDR, we will still be using
RIPv1 for routing and for good or for bad we will never have MP-BGP ...
just to quote 1% of breaking the "always" rules.

I am not getting why IPv6 ministers are like monks in deepest Bhutan's
Monasteries. The banner is: "What has been defined years back is the only
truth forever."

Maybe it is time to open the windows and ask yourself why IPv6 deployment
for end consumers is really not happeing (except very local markets like
Japan). Maybe IPv6 did not come with suficient reason to be deployed ???

Maybe it came with way too much baggage not to be deployed .. example hosts
force to pick which PA address to use as src .... this is so broken !

IMHO if we can not give PI to everyone we are doing something very wrong.

And no further then last IETF I had one vendor person coming to me after
comment at RTGWG that PI for IPv6 is not so great idea that I immediately
understood why IPv6 is in such poor state. He insisted everyone should use
PA space. Is this what you all recommend ???

Bottom line if IPv6 gurus think today that what has been defined years back
it is to stay as "basic rule" for v6 in the years to come I can only wish
you all the best.

Cheers,
Robert.

PS. Folks like Stefano and myself do know very well traveling the world to
educate folks to deploy new technologies that it only get's good traction
where there is good reason for it. Clearly depletion of v4 space as real
life shows was not the reason for v6 to gain global momentum. Even folks at
various conferencs admit it these days.

---

From: Mark Smith <[email-masked]>
Date: Sun, 30 Apr 2017 13:07:05 +1000

On 30 Apr. 2017 11:48, "Robert Raszuk" <[email-masked]> wrote:

Bert

Dear Bert,

None of those made structural or size changes to IPv4 packets while
in-flight. They were control plane protocol changes or forwarding
processing changes that left the format of the packet and the semantics of
its field values alone.

(And no, MPLS or any other link layer encapsulation is not changing the
IPv4 packet - the range of octets starting at the IPv4 header extending
through to the end of the IPv4 payload. Same with an IPv6 packet.)

Your proposed change is unprecedented. No other network layer protocol as
far as I'm aware, including IPv4, IPX and Appletalk (I'm pretty confident
if DECnet and CLNS too) have made structural changes to their network layer
PDUs while in-flight.

An unprecedented change may not be trivial, and certainly shouldn't be
classified as such during a document maintenance​ update to a 18+ year old
protocol like IPv6.

You're out of touch with IPv6 deployment status.

https://www.google.com/intl/en/ipv6/statistics.html

https://stats.labs.apnic.net/ipv6/

We have an installed base of billions of IPv6 capable devices that expect
RFC2460 behaviour to look after.

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.

Regards,
Mark.

Cheers,
Robert.

CGN capacity/throughput costs and the opex of running two protocols will
get them in the end.

---

From: Fred Baker <[email-masked]>
Date: Sat, 29 Apr 2017 23:40:20 -0700

On Apr 29, 2017, at 8:07 PM, Mark Smith <[email-masked]> wrote:
> On Apr 29, 2017, at 6:45 PM, Robert Raszuk <[email-masked]> wrote:
>> Maybe it is time to open the windows and ask yourself why IPv6 deployment for end consumers is really not happening (except very local markets like Japan). Maybe IPv6 did not come with suficient reason to be deployed ???
> 

Robert, you might be interested to poke around on the current status of IPv6 deployment. Here are 36 countries, of which Google says that 5% or more of the traffic from them uses IPv6. Consider the implications of that, if you would; it means that someone had a computer that was attached to a network attached to an ISP attached to another ISP that went to Google to a computer, and every step along the way IPv6 was deployed and working, end to end. 

https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=be,us,gr,de,ch,lu,in,br,ee,ca,ec,jp,gb,pt,my,fr,tt,no,fi,pe,au,cz,nz,nl,ie,ro,hu,si,zw,gt,pr,kr,vn,sa,at,ax,pl

That includes countries on every continent, including Zimbabwe in Africa, six Latin American countries, Saudi Arabia, Malaysia, and India. And, oh yes, Japan. And the US.

Heck, look at Trinidad and Tobago, a Small Island State in the Caribbean, someone that the UN considers to be seriously back woods. Google says that 15% of the sessions they have in T&T use IPv6, and Akamai says that 20% of the traffic they deliver there uses IPv6. This isn't just the big countries, or the well-connected ones.

https://www.vyncke.org/ipv6status/project.php?metric=p&country=tt
https://www.vyncke.org/ipv6status/project.php?metric=k&country=tt

At F Root, about 11% of our DNS accesses come in IPv6 packets.

http://rssac-stats.isc.org/rssac002/2017

Several companies are taking serious steps toward turning IPv4 off, or have already done so. Where is IPv6 dominant? The Mobile networks are among the biggest there.

https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft
https://blog.apnic.net/2017/02/02/addressing-in-2016
https://blog.apnic.net/2017/02/07/reliance-jio-boosts-india-past-20-ipv6-capability
https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-only-infra
https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf 
https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_13462152832-2.pdf

Performance issues that were there historically, largely due to substandard routing, are a bad memory.
https://blog.apnic.net/2016/08/22/ipv6-performance-revisited

You might be interested in Uber's viewpoint.

https://eng.uber.com/ipv6

"Having deployment problems" isn't a very accurate statement.

It is fair to say that the deployment started slowly. It started in 2006, with ICANN ratifying a policy for the allocation of IPv6 prefixes, and the limited-IPv6-capability Windows Vista release in the same year (other platforms all had it, Windows was the laggard, and killing off Windows XP has been an quest worthy of Arthur). By 2009, 4000 prefixes had been allocated world-wide. IPv4 exhaustion at IANA was predicted, although there was a lot of discussion between Geoff and Tony, and finally happened in January 2011. April 2011, APNIC entered their final phase of IPv4 allocation (by policy, they now only allocate a /22 to a new member, and none at all to existing members), and at this point all five RIRs are in their final phase of IPv4 allocation. The IPv4 Market Group says that they expect the price of an IPv4 address, which right now varies between about $6 and $15 per address depending on the block size, to start to decline in 2019, because at that point more than half of the users in the world will have functional IPv6 capabilities and it will be in corporate interest to look forward rather than back. Swisscom says that by 2024 they expect they won't have enough IPv4 traffic to justify continuing to route it.

https://www.icann.org/news/announcement-2006-09-11-en
https://www.oecd.org/sti/ieconomy/44961688.pdf slide 16
https://ipv4.potaroo.net/
http://ipv4marketgroup.com/ipv4-pricing-in-a-post-arin-runout-world
http://ipv4marketgroup.com/q42016-update
http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Status_Roadmap_and_Outlook_IPv6.pdf

In other words, it didn't start until the IPv4 address space became exhausted at IANA and the relevant RIRs, which was 100% predictable. At this point, smart companies are starting to use the speculative asset of IPv4 address space to finance their IPv6 deployment, and some companies are starting to charge for IPv4 address space while leaving IPv6 free.

https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4cce0
http://www.networkworld.com/article/3191503/internet/mit-selling-8-million-coveted-ipv4-addresses-amazon-a-buyer.html
https://www.mythic-beasts.com/order/vps

If you are on a major broadband service in the US and don't have IPv6 in your home (go to http://www.kame.net, and see if the turtle dances), ask your provider about it. There's a good chance the issue is at your residential router.

You're welcome to your opinions of IPv6; if it were mine to do over there are some things I might change. But it is what it is, and it's out there. Get used to it. Resistance, as they say, is futile.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Sun, 30 Apr 2017 23:56:54 +0000

From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Date: Saturday, April 29, 2017 at 11:07 PM
To: Robert Raszuk <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: Proposed revised Extension Header text for rfc2460bis

On 30 Apr. 2017 11:48, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:
So innovate without violating basic rules, on the open Internet. Or violate the rules all you like, but make sure it is only among "consenting adults," which means, in a local domain. It's always been this way, so this should not come as a surprise?

Bert

Dear Bert,

To your quote "It's always been this way" I completely and respectfully disagree.

If the IETF would be stuck in not violating on what you call "basic rules" we would still be classfull and never use CIDR, we will still be using RIPv1 for routing and for good or for bad we will never have MP-BGP ... just to quote 1% of breaking the "always" rules.

None of those made structural or size changes to IPv4 packets while in-flight. They were control plane protocol changes or forwarding processing changes that left the format of the packet and the semantics of its field values alone.

(And no, MPLS or any other link layer encapsulation is not changing the IPv4 packet - the range of octets starting at the IPv4 header extending through to the end of the IPv4 payload. Same with an IPv6 packet.)

Your proposed change is unprecedented. No other network layer protocol as far as I'm aware, including IPv4, IPX and Appletalk (I'm pretty confident if DECnet and CLNS too) have made structural changes to their network layer PDUs while in-flight.

An unprecedented change may not be trivial, and certainly shouldn't be classified as such during a document maintenance​ update to a 18+ year old protocol like IPv6.

I am not getting why IPv6 ministers are like monks in deepest Bhutan's Monasteries. The banner is: "What has been defined years back is the only truth forever."

Maybe it is time to open the windows and ask yourself why IPv6 deployment for end consumers is really not happeing (except very local markets like Japan). Maybe IPv6 did not come with suficient reason to be deployed ???

Maybe it came with way too much baggage not to be deployed .. example hosts force to pick which PA address to use as src .... this is so broken !

And no further then last IETF I had one vendor person coming to me after comment at RTGWG that PI for IPv6 is not so great idea that I immediately understood why IPv6 is in such poor state. He insisted everyone should use PA space. Is this what you all recommend ???

Bottom line if IPv6 gurus think today that what has been defined years back it is to stay as "basic rule" for v6 in the years to come I can only wish you all the best.

We have an installed base of billions of IPv6 capable devices that expect RFC2460 behaviour to look after.

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”.

Regards,
Mark.

Cheers,
Robert.

PS. Folks like Stefano and myself do know very well traveling the world to educate folks to deploy new technologies that it only get's good traction where there is good reason for it. Clearly depletion of v4 space as real life shows was not the reason for v6 to gain global momentum. Even folks at various conferencs admit it these days.

CGN capacity/throughput costs and the opex of running two protocols will get them in the end.

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

---

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

I agree and support.

dan

    
    
    s.

---

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

On 2017-04-29, 6:55 PM, "ipv6 on behalf of Manfredi, Albert E" <[email-masked] on behalf of [email-masked]> wrote:

    

I support Robert R. here, operators need innovations which may requires to re-visit some rules. The IETF “MUST NOT” become a bottleneck for change, it requires an open mind.

With that said; are we saying the following “but not by violating certain fundamental rules” with in mind that allow a “header insertion is “violating a “fundamental rules” ? I don’t understand why in this list we are now at that extreme ?

    Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 1 May 2017 10:29:44 +1000

On 1 May 2017 at 09:56, Voyer, Daniel <[email-masked]> wrote:
<snip>
>
>
> Your SPRING group is operating in currently a very small green field (are
> 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?

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

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.