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

[<[e-mail]>]

Fred,

Of course!

Also, our Destination Option can be used for traffic other than TLS.   In fact, any IPv6 traffic.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone]

--------------------------------------------
On Fri, 4/14/17, Templin, Fred L <[e-mail]> wrote:

 Subject: RE: Deprecation of IPv6 atomic fragments (some good news)
 To: "[e-mail]" <[e-mail]>, "Fernando Gont" <[e-mail]>, "[e-mail]" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>
 Date: Friday, April 14, 2017, 9:49 AM
 
 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: [e-mail]
 [mailto:[e-mail]]
 > Sent: Friday, April 14, 2017 9:37 AM
 > To: [e-mail];
 Fernando Gont <[e-mail]>;
 [e-mail];
 Templin, Fred L
 > <[e-mail]>
 > Cc: [e-mail]
 > 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
 > [phone]
 > 
 >
 --------------------------------------------
 > On Fri, 4/14/17, Templin, Fred L <[e-mail]>
 wrote:
 > 
 >  Subject:
 RE: Deprecation of IPv6 atomic fragments (some good news)
 >  To: "[e-mail]"
 <[e-mail]>,
 "Fernando Gont" <[e-mail]>,
 > "[e-mail]"
 <[e-mail]>
 >  Cc: "[e-mail]"
 <draft-ietf-6man-deprecate-atomfrag-
 >
 [e-mail]>
 >  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: [e-mail]
 >  [mailto:[e-mail]]
 >  > Sent: Friday, April 14, 2017 9:00
 AM
 >  > To: [e-mail];
 >  Fernando Gont <[e-mail]>;
 >  [e-mail];
 >  Templin, Fred L
 > 
 > <[e-mail]>
 >  > Cc: [e-mail]
 >  > 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
 <[e-mail]>
 >  wrote:
 >  >
 >  >  Subject:
 > 
 RE: Deprecation of IPv6 atomic fragments (some good news)
 >  >  To: "[e-mail]"
 >  <[e-mail]>,
 >  "Fernando Gont" <[e-mail]>,
 >  > "[e-mail]"
 >  <[e-mail]>
 >  >  Cc: "[e-mail]"
 > 
 <draft-ietf-6man-deprecate-atomfrag-
 >  >
 >  [e-mail]>
 >  >  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:[e-mail]]
 >  >  On Behalf Of Templin, Fred L
 >  >  > Sent:
 > 
 >
 >  Friday, April 14, 2017 8:50
 AM
 >  >  >
 > 
 To: [e-mail];
 >  >  Fernando Gont <[e-mail]>;
 >  >  [e-mail]
 >  >  > Cc: [e-mail]
 >  >  > Subject: RE: Deprecation of
 IPv6
 >  atomic
 > 
 >  fragments (some good news)
 > 
 >  >
 >  >  > Very
 >  good. Thanks.
 > 
 >  >
 >  >
 >  >  > Fred
 > 
 >  >
 >  >  > >
 >  -----Original Message-----
 >  >  > >
 > 
 From: [e-mail]
 >  >  [mailto:[e-mail]]
 >  >  > > Sent: Friday, April 14,
 2017
 >  8:45
 > 
 >  AM
 >  >  >
 >  > To: Fernando Gont <[e-mail]>;
 >  >  [e-mail];
 >  >  Templin, Fred L <[e-mail]>
 >  >  > > Cc: [e-mail]
 >  >  > > 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
 >  >  >
 >
 >  [phone]
 >  >  >
 > 
 >  >
 >  >  > >
 >  >
 > 
 --------------------------------------------
 >  >  > > On Fri, 4/14/17,
 Templin, Fred
 >  L
 >  >  <[e-mail]>
 >  >  wrote:
 > 
 >  >
 >  >
 >  >  > >
 > 
 >
 >  Subject: RE: Deprecation of IPv6
 atomic fragments (some
 >  good
 >  >  news)
 > 
 >
 >  > >  To:
 "Fernando
 >  >
 >  Gont" <[e-mail]>,
 >  >  "[e-mail]"
 >  >  <[e-mail]>
 >  >  > >  Cc: "[e-mail]"
 >  >
 > 
 <draft-ietf-6man-deprecate-atomfrag-
 >  >  >
 > 
 >  > [e-mail]>
 >  >  > >  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:[e-mail]]
 >  >  > >  On Behalf Of
 Fernando
 >  Gont
 > 
 >  > >  > Sent:
 >  > 
 >
 >  >  >
 >  Friday, April 14, 2017 8:28 AM
 >  >
 >  >
 >  >  >  > To: [e-mail]
 >  >  > >  > Cc: [e-mail]
 >  >  > >  > 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: [e-mail]
 >  >  > >  || [e-mail]
 >  >  > >  > PGP Fingerprint:
 7809
 >  84F5
 > 
 >  322E 45C7 F1C9
 >  >  >
 >  3945 96EE A9EF
 >  >  D076
 FFF1
 >  >  >
 >  >  >
 > 
 >  > >  >
 >  >  >
 >
 >  >  >
 >  >  > >  >
 >  >
 >  >
 >  >  >
 > 
 >
 > 
 --------------------------------------------------------------------
 >  >  > >  > IETF IPv6
 working
 >  group
 > 
 >  mailing list
 >  >  >
 >  > [e-mail]
 >  >  > >  >
 Administrative
 >  Requests: https://www.ietf.org/mailman/listinfo/ipv6
 >  >  >
 > 
 >  >
 >  >
 >  >  > >
 > 
 >
 > 
 --------------------------------------------------------------------
 >  >  > >
 > 
 >  >
 >  >
 >  >  > >
 > 
 >
 > 
 --------------------------------------------------------------------
 >  >  > >  IETF IPv6 working
 group
 >  mailing
 > 
 >  list
 >  >
 >  > >  [e-mail]
 >  >  > >  Administrative
 Requests: https://www.ietf.org/mailman/listinfo/ipv6
 >  >  > >
 > 
 >
 > 
 --------------------------------------------------------------------
 >  >  > >
 > 
 >  >
 >  >  >
 >  >
 > 
 --------------------------------------------------------------------
 >  >  > IETF IPv6 working group
 mailing
 >  list
 > 
 >  > [e-mail]
 >  >  > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
 >  >  >
 > 
 >
 > 
 --------------------------------------------------------------------
 >  >
 >  >
 > 
 >