RE: Deprecation of IPv6 atomic fragments (some good news)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 14 April 2017 16:50 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43031294CE for <ipv6@ietfa.amsl.com>; Fri, 14 Apr 2017 09:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKjE66aE9JIQ for <ipv6@ietfa.amsl.com>; Fri, 14 Apr 2017 09:49:59 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFA1129421 for <6man@ietf.org>; Fri, 14 Apr 2017 09:49:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EGnw2Z022579; Fri, 14 Apr 2017 09:49:58 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EGnmG2022512 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 09:49:48 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 09:49:47 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 09:49:47 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>, Fernando Gont <fernando@gont.com.ar>, "6man@ietf.org" <6man@ietf.org>
CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" <draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org>
Subject: RE: Deprecation of IPv6 atomic fragments (some good news)
Thread-Topic: Deprecation of IPv6 atomic fragments (some good news)
Thread-Index: AQHStT1O1hK2AEEwp0Wezupmp4l/LKHFEMNA
Date: Fri, 14 Apr 2017 16:49:47 +0000
Message-ID: <7726e86558b141d6891f5e18f3ce437f@XCH15-06-08.nw.nos.boeing.com>
References: <1197525357.563762.1492187807985.ref@mail.yahoo.com> <1197525357.563762.1492187807985@mail.yahoo.com>
In-Reply-To: <1197525357.563762.1492187807985@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/x4_1Mx2torJDi62oedgSkVmzLmo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Apr 2017 16:50:02 -0000

Hi Nalini,

I don't want to be misunderstood - I support what you are proposing.
In terms of tunneling, however, we are using TLS in some of our internal
code and it looks like TLS provides a 64-bit sequence number that we
are using for DPD (also reordering detection).

But, as I think you are implying, the tunnel is only one link in what may
be an IPv6 path over many links. So, it could be that the raw IPv6 packet
may still want to include one of your options in case duplication might
occur somewhere along the remaining IPv6 path once the packet
emerges from the tunnel. So, I think it is OK.

Thanks - Fred

> -----Original Message-----
> From: nalini.elkins@insidethestack.com [mailto:nalini.elkins@insidethestack.com]
> Sent: Friday, April 14, 2017 9:37 AM
> To: nalini.elkins@insidethestack.com; Fernando Gont <fernando@gont.com.ar>; 6man@ietf.org; Templin, Fred L
> <Fred.L.Templin@boeing.com>
> Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org
> Subject: RE: Deprecation of IPv6 atomic fragments (some good news)
> 
> Fred,
> 
> Very interesting comments.
> 
> One thing, the Destination Option is set by the end host(s).   Of course, the devices in the middle, if those are doing the encapsulation
> rather than the end host, could certainly examine the Destination Option.
> 
> As far as implementation, we are starting on code in the FreeBSD kernel at the end of next week & I have already had two other
> requests for code samples.   I believe that at least one person (other than us!) has already started on implementation.   Let's see how
> this rolls!
> 
> Thanks,
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> --------------------------------------------
> On Fri, 4/14/17, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> 
>  Subject: RE: Deprecation of IPv6 atomic fragments (some good news)
>  To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>, "Fernando Gont" <fernando@gont.com.ar>,
> "6man@ietf.org" <6man@ietf.org>
>  Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" <draft-ietf-6man-deprecate-atomfrag-
> generation@tools.ietf.org>
>  Date: Friday, April 14, 2017, 9:22 AM
> 
>  Hi Nalini,
> 
>  OK. But, tunnel encapsulations frequently
>  include 32-bit Identification values
>  (GRE,
>  GUE, IPsec, others) which can be used for DPD so I was
>  wondering if a
>  similar facility was
>  available for raw IPv6 packets. It sounds like with the
>  PSN feature your document is providing there is
>  opportunity for DPD but
>  in a different way
>  than widely-deployed tunneling systems currently do it.
> 
>  I think we had this same
>  conversation at one of the recent meetings, but
>  I am left wondering whether having two
>  different ways of doing DPD will
>  be
>  confusing to implementers. Maybe what you have is better,
>  but will
>  widely-deployed networking gear be
>  overhauled to pick up the new
>  feature?
> 
>  Thanks - Fred
> 
>  > -----Original Message-----
>  > From: nalini.elkins@insidethestack.com
>  [mailto:nalini.elkins@insidethestack.com]
>  > Sent: Friday, April 14, 2017 9:00 AM
>  > To: nalini.elkins@insidethestack.com;
>  Fernando Gont <fernando@gont.com.ar>;
>  6man@ietf.org;
>  Templin, Fred L
>  > <Fred.L.Templin@boeing.com>
>  > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org
>  > Subject: RE: Deprecation of IPv6 atomic
>  fragments (some good news)
>  >
>  > You can use the sequence number (PSN) in
>  combination with the other fields
>  >
>  > PSNTP      : Packet Sequence Number
>  This Packet
>  > PSNLR      : Packet
>  Sequence Number Last Received
>  > DELTATLR
>  : Delta Time Last Received
>  > DELTATLS :
>  Delta Time Last Sent
>  >
>  > to get quite a good idea of duplicate
>  packets.   You can also differentiate duplicate packets
>  from retransmissions.
>  >
>  > Thanks,
>  >
>  > Nalini Elkins
>  > CEO and
>  Founder
>  > Inside Products, Inc.
>  > www.insidethestack.com
>  > (831) 659-8360
>  >
>  >
>  --------------------------------------------
>  > On Fri, 4/14/17, Templin, Fred L <Fred.L.Templin@boeing.com>
>  wrote:
>  >
>  >  Subject:
>  RE: Deprecation of IPv6 atomic fragments (some good news)
>  >  To: "nalini.elkins@insidethestack.com"
>  <nalini.elkins@insidethestack.com>,
>  "Fernando Gont" <fernando@gont.com.ar>,
>  > "6man@ietf.org"
>  <6man@ietf.org>
>  >  Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org"
>  <draft-ietf-6man-deprecate-atomfrag-
>  >
>  generation@tools.ietf.org>
>  >  Date: Friday, April 14, 2017, 8:53 AM
>  >
>  >  Oh, I just looked
>  and saw that
>  >  the option presents
>  16-bit Packet Sequence Numbers.
>  >  I was
>  thinking 32 for use cases such as
>  >
>  Duplicate Packet Detection. Is there any way to
>  >  get a 32-bit Identification?
>  >
>  >  Thanks - Fred
>  >
>  >  >
>  -----Original
>  >  Message-----
>  >  > From: ipv6 [mailto:ipv6-bounces@ietf.org]
>  >  On Behalf Of Templin, Fred L
>  >  > Sent:
>  >
>  Friday, April 14, 2017 8:50 AM
>  >  >
>  To: nalini.elkins@insidethestack.com;
>  >  Fernando Gont <fernando@gont.com.ar>;
>  >  6man@ietf.org
>  >  > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org
>  >  > Subject: RE: Deprecation of IPv6
>  atomic
>  >  fragments (some good news)
>  >  >
>  >  > Very
>  good. Thanks.
>  >  >
>  >
>  >  > Fred
>  >  >
>  >  > >
>  -----Original Message-----
>  >  > >
>  From: nalini.elkins@insidethestack.com
>  >  [mailto:nalini.elkins@insidethestack.com]
>  >  > > Sent: Friday, April 14, 2017
>  8:45
>  >  AM
>  >  >
>  > To: Fernando Gont <fernando@gont.com.ar>;
>  >  6man@ietf.org;
>  >  Templin, Fred L <Fred.L.Templin@boeing.com>
>  >  > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org
>  >  > > Subject: RE: Deprecation of
>  IPv6
>  >  atomic fragments (some good
>  news)
>  >  >
>  >
>  >
>  >  > > Fred,
>  >  >
>  >  >
>  >  > > For sequence numbers in
>  IPv6,
>  >  You may wish to look at
>  >  > >
>  >  >
>  > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
>  >  > >
>  >  >
>  > which was
>  >  on the telechat agenda
>  for Thursday.   We will be
>  >
>  addressing all the comments & hope to be rolling
>  quite
>  >  soon.
>  >
>  > >
>  >  > >
>  >  Thanks,
>  >  >
>  >
>  >  > >
>  >
>  Nalini Elkins
>  >  > > CEO and
>  Founder
>  >  > > Inside Products,
>  Inc.
>  >  > >
>  www.insidethestack.com
>  >  > >
>  (831) 659-8360
>  >  >
>  >  >
>  >  > >
>  >
>  --------------------------------------------
>  >  > > On Fri, 4/14/17, Templin, Fred
>  L
>  >  <Fred.L.Templin@boeing.com>
>  >  wrote:
>  >  >
>  >
>  >  > >
>  >
>  Subject: RE: Deprecation of IPv6 atomic fragments (some
>  good
>  >  news)
>  >
>  > >  To: "Fernando
>  >
>  Gont" <fernando@gont.com.ar>,
>  >  "6man@ietf.org"
>  >  <6man@ietf.org>
>  >  > >  Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org"
>  >
>  <draft-ietf-6man-deprecate-atomfrag-
>  >  >
>  >  > generation@tools.ietf.org>
>  >  > >  Date: Friday, April 14,
>  2017, 8:40
>  >  AM
>  >
>  > >
>  >  > >  Hi
>  >  Fernando,
>  >  >
>  >
>  >  >
>  >
>  >  With the deprecation of atomic fragments, is
>  >  > >  there another way to
>  include
>  >  > >  an
>  >  > >
>  >
>  Identification value in the header of an IPv6 packet? Do
>  >  we
>  >  > >
>  need a new
>  >  > >  extension
>  header or destination
>  >  > >
>  option for that?
>  >  > >
>  >  > >  Thanks
>  >  -
>  >  > >
>  Fred
>  >  >
>  >
>  >
>  >  > >  >
>  -----Original
>  >  > >
>  Message-----
>  >  >
>  >  >  > From: ipv6 [mailto:ipv6-bounces@ietf.org]
>  >  > >  On Behalf Of Fernando
>  Gont
>  >  > >  > Sent:
>  >  >
>  >  >
>  Friday, April 14, 2017 8:28 AM
>  >
>  >
>  >  >  > To: 6man@ietf.org
>  >  > >  > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org
>  >  > >  > Subject: Deprecation of
>  IPv6
>  >  atomic
>  >
>  > >  fragments (some good
>  >
>  news)
>  >  > >  >
>  >  >
>  >  >  >
>  Folks,
>  >  > >  >
>  >  > >  > Thought it might be
>  good
>  >  feedback for the
>  >  > >  group. Juniper
>  >  published a
>  >  >
>  >  >
>  >  > >  vulnerability
>  advisory with patches
>  >  for the issue
>  discussed
>  >  > >  in
>  >  RFC8021:
>  >  >
>  >  > <https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10780&actp=SUBSCRIPTION>
>  >  > >  >
>  >
>  > >
>  >  > Besides providing
>  >  > >  the
>  >
>  rationale for the change in rfc2460bis and
>  >  > >  > RFC7915, this kind of
>  thing
>  >  was one of the
>  >  > >  motivations for
>  >  working on
>  >  >
>  >  > such RFC.
>  >  > >
>  >
>  >  > >
>  >
>  > Thanks!
>  >  > >  >
>  >  > >  > Cheers,
>  >  >
>  >  >  >
>  --
>  >  > >  > Fernando
>  >  Gont
>  >  > >
>  > e-mail: fernando@gont.com.ar
>  >  > >  || fgont@si6networks.com
>  >  > >  > PGP Fingerprint: 7809
>  84F5
>  >  322E 45C7 F1C9
>  >  > >  3945 96EE A9EF
>  >  D076 FFF1
>  >  >
>  >  >
>  >  > >  >
>  >  > >
>  >  >
>  >  > >  >
>  >
>  >
>  >  >
>  >
>  --------------------------------------------------------------------
>  >  > >  > IETF IPv6 working
>  group
>  >  mailing list
>  >  > >  > ipv6@ietf.org
>  >  > >  > Administrative
>  Requests: https://www.ietf.org/mailman/listinfo/ipv6
>  >  >
>  >  >
>  >
>  >  > >
>  >
>  --------------------------------------------------------------------
>  >  > >
>  >  >
>  >
>  >  > >
>  >
>  --------------------------------------------------------------------
>  >  > >  IETF IPv6 working group
>  mailing
>  >  list
>  >
>  > >  ipv6@ietf.org
>  >  > >  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>  >  > >
>  >
>  --------------------------------------------------------------------
>  >  > >
>  >  >
>  >  >
>  >
>  --------------------------------------------------------------------
>  >  > IETF IPv6 working group mailing
>  list
>  >  > ipv6@ietf.org
>  >  > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>  >  >
>  >
>  --------------------------------------------------------------------
>  >
>  >
> 
>