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

From: <[email-masked]>
Date: Fri, 14 Apr 2017 16:36:47 +0000 (UTC)

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 <[email-masked]> wrote:

 Subject: RE: Deprecation of IPv6 atomic fragments (some good news)
 To: "[email-masked]" <[email-masked]>, "Fernando Gont" <[email-masked]>, "[email-masked]" <[email-masked]>
 Cc: "[email-masked]" <[email-masked]>
 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: [email-masked]
 [mailto:[email-masked]]
 > Sent: Friday, April 14, 2017 9:00 AM
 > To: [email-masked];
 Fernando Gont <[email-masked]>;
 [email-masked];
 Templin, Fred L
 > <[email-masked]>
 > Cc: [email-masked]
 > 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 <[email-masked]>
 wrote:
 >  Subject:
 RE: Deprecation of IPv6 atomic fragments (some good news)
 >  To: "[email-masked]"
 <[email-masked]>,
 "Fernando Gont" <[email-masked]>,
 > "[email-masked]"
 <[email-masked]>
 >  Cc: "[email-masked]"
 <draft-ietf-6man-deprecate-atomfrag-
 [email-masked]>
 >  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:[email-masked]]
 >  On Behalf Of Templin, Fred L
 >  > Sent:
 > 
 Friday, April 14, 2017 8:50 AM
 >  >
 To: [email-masked];
 >  Fernando Gont <[email-masked]>;
 >  [email-masked]
 >  > Cc: [email-masked]
 >  > Subject: RE: Deprecation of IPv6
 atomic
 >  fragments (some good news)
 >  >
 >  > Very
 good. Thanks.
 >  >
 >  > Fred
 >  >
 >  > >
 -----Original Message-----
 >  > >
 From: [email-masked]
 >  [mailto:[email-masked]]
 >  > > Sent: Friday, April 14, 2017
 8:45
 >  AM
 >  >
 > To: Fernando Gont <[email-masked]>;
 >  [email-masked];
 >  Templin, Fred L <[email-masked]>
 >  > > Cc: [email-masked]
 >  > > 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
 >  <[email-masked]>
 >  wrote:
 >  >
 >
 >  > >
 > 
 Subject: RE: Deprecation of IPv6 atomic fragments (some
 good
 >  news)
 > >  To: "Fernando
 Gont" <[email-masked]>,
 >  "[email-masked]"
 >  <[email-masked]>
 >  > >  Cc: "[email-masked]"
 > 
 <draft-ietf-6man-deprecate-atomfrag-
 >  >
 >  > [email-masked]>
 >  > >  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:[email-masked]]
 >  > >  On Behalf Of Fernando
 Gont
 >  > >  > Sent:
 >  >
 >  > 
 Friday, April 14, 2017 8:28 AM
 > 
 >
 >  >  > To: [email-masked]
 >  > >  > Cc: [email-masked]
 >  > >  > 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: [email-masked]
 >  > >  || [email-masked]
 >  > >  > PGP Fingerprint: 7809
 84F5
 >  322E 45C7 F1C9
 >  > >  3945 96EE A9EF
 >  D076 FFF1
 >  >
 >  >
 >  > >  >
 >  > >
 >  >
 >  > >  >
 >  >
 --------------------------------------------------------------------
 >  > >  > 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: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Apr 2017 16:49:47 +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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 14, 2017 9:37 AM
> To: [email-masked]; Fernando Gont <[email-masked]>; [email-masked]; Templin, Fred L
> 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
>