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

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

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]" <[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:22:56 +0000

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

> 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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Apr 2017 14:21:54 -0400

Templin, Fred L <[email-masked]> wrote:
    > 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.

You could insert an AH header with a reserved SPI# if you control the end
points such that they can be verified to be willing to skip that.

I'd rather like to update the IPv6 host requirements to say that
unknown AH SPI# are to be skipped as if not even there.

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