Subject: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

From: Ronald Bonica <[email-masked]>
Date: Thu, 20 Jun 2013 15:55:11 +0000

Folks,

Please review this draft and provide comments.

                      Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 20, 2013 11:48 AM
> To: Ronald Bonica
> Subject: New Version Notification for draft-bonica-6man-frag-deprecate-
> 00.txt
> 
> 
> A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Filename:	 draft-bonica-6man-frag-deprecate
> Revision:	 00
> Title:		 IPv6 Fragment Header Deprecated
> Creation date:	 2013-06-20
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-bonica-6man-
> frag-deprecate-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-bonica-6man-
> frag-deprecate
> Htmlized:        http://tools.ietf.org/html/draft-bonica-6man-frag-
> deprecate-00
> 
> 
> Abstract:
>    This memo deprecates the IPv6 Fragment Header.  It provides reasons
>    for deprecation and updates RFC 2460.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Jun 2013 23:36:57 +0700

Ron, Warren

    In general I tent to agree with you.

    Would you have references or data to back up these two statements?

1) " Most popular TCP [RFC0793] implementations leverage this technology
   and restrict their segment size so that IP fragmentation is not
   required."
2) " As a result, IPv6 fragments carrying TCP payload are
   rarely observed on the Internet."

Regards,
as

On 6/20/13 10:55 PM, Ronald Bonica wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Jun 2013 13:56:56 -0700 (PDT)

Hi,

I also tend to agree with this draft. However, I'm wondering about how this will effect non-UDP/TCP protocols that assume IP layer fragmentation to take care of their larger payloads e.g, OSPF?

SCTP and DCCP might also be worth looking at - hopefully their deployment will increase due to no NATs in IPv6.

Also, the impact on tunnel protocols such as GRE and IPsec might be worth both considering and discussing. It is a while since I spent time in this area, however I remember there are commonly options or defaults to either set the DF flag universally on the outer tunnel packet, or to copy the DF value from the inner packet. For at least GRE and IPsec, the tunnel protocols themselves don't independently perform periodic PMTUD between the tunnel endpoints to determine tunnel MTU.

Regards,
Mark.

----- Original Message -----
> From: Ronald Bonica <[email-masked]>
> To: "[email-masked] 6man-wg" <[email-masked]>
> Cc: 
> Sent: Friday, 21 June 2013 1:55 AM
> Subject: FW: New Version Notification for
	draft-bonica-6man-frag-deprecate-00.txt

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 21 Jun 2013 11:03:08 +0300

I really like this idea.
What worries me is the different cases to be examined/solved depending on the source device: host (applications) or router (protocols).
And this draft takes into account mostly the first.

--
Tassos

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Jun 2013 10:22:45 +0200

> I really like this idea.

+1

> And this draft takes into account mostly the first.

Impacts on SIIT [RFC6145] would also need to be analyzed. Fun fun fun! ;)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Jun 2013 16:29:02 +0000

Hi Tassos,

Thanks for reviewing the draft. Could you provide more detail on what is missing?

                             Ron

> From: Tassos Chatzithomaoglou [mailto:[email-masked]]
> Sent: Friday, June 21, 2013 4:03 AM
> To: Ronald Bonica; [email-masked] 6man-wg
> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
> 
> I really like this idea.
> What worries me is the different cases to be examined/solved depending
> on the source device: host (applications) or router (protocols).
> >> Subject: New Version Notification for
> >> draft-bonica-6man-frag-deprecate- 00.txt
> >>
> >>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Jun 2013 19:03:50 +0200

I have also read this draft.

It mentions that DNSSEC will be impacted.

What's the alternative if DNSSEC can't send multiple UDP fragments?

Isn't expecting a busy DNS server to maintain TCP session state for
every single query going to be prohibitively expensive?
Leading to even bigger DoS worries than fragmentation apparently causes?

Isn't using TCP for all DNS queries going to considerably slow down the
name resolution process, which will impact all applications?
(multiple RTT for the connection establishment and teardown if you clean
up properly)

Since PMTUD is also currently pretty broken in practice, also due to
"Operator Behavior" and filtering of ICMPv6 in firewalls, doesn't this
memo effectively state that IPv6 = 1280 octets?

regards,
RayH

---

From: joel jaeggli <[email-masked]>
Date: Fri, 21 Jun 2013 10:19:56 -0700

> What's the alternative if DNSSEC can't send multiple UDP fragments?
so I'm pretty sure I don't want to expose myself to really big replies 
because that pushed the opportunity to amplify considerably.

so EDNS0  limited to ~1420 or ~1280 I could probably live with.
> every single query going to be prohibitively expensive?
handshakes are expensive yes, and imho signficant effort should be 
engaged in to avoid that.
> Leading to even bigger DoS worries than fragmentation apparently causes?
The cost shifts. I'm not that excited about making connections over TCP 
unless I have to.
> memo effectively state that IPv6 = 1280 octets?
So, I'm not willing to throw up my hands in despair over PMTUD yet. 
there are certianly cases where it doesn't work. they're a little less 
chronic then not being able to find the L4 header.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Jun 2013 19:00:51 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Arturo Servin
> Sent: Thursday, June 20, 2013 12:37 PM
> To: [email-masked]

The best references that I can find are in user documentation. However, I thought that it would be inappropriate to reference user documentation in an IETF document.

AFAIKS, the Microsoft, Apple, Linux and FreeBSD TCP implementations all leverage PMTUD. However, I am not an expert on any of those platforms and invite people who are to comment.

>    rarely observed on the Internet."

I don't know of a study. However, this is probably a safe assumption considering that:

- many TCP implementation leverage PMTUD
- many enterprise block fragments
- many firewalls, by default, block IPv6 fragments

                                 Ron

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Jun 2013 19:12:25 +0000

Ray,

Joel has already responded regarding DNSSEC. However, I would like to add a word regarding PMTUD brokenness.

If the bad operator behavior to which you refer is the filtering of ICMP PTB messages, that bad behavior will break IPv6 fragmentation to the same degree that it breaks PMTUD. So, keeping IPv6 fragmentation around won't help very much.

                                                Ron

> From: Ray Hunter [mailto:[email-masked]]
> Sent: Friday, June 21, 2013 1:04 PM
> To: Ronald Bonica
> Cc: Tassos Chatzithomaoglou; [email-masked] 6man-wg
> Subject: Re: RE: FW: New Version Notification for draft-bonica-6man-
> frag-deprecate-00.txt
> 
> (multiple RTT for the connection establishment and teardown if you
> clean up properly)
>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Jun 2013 21:44:03 +0200

> Ronald Bonica <mailto:[email-masked]>
> 21 June 2013 21:12
> Ray,
>
> If the bad operator behavior to which you refer is the filtering of
> ICMP PTB messages, that bad behavior will break IPv6 fragmentation to
> the same degree that it breaks PMTUD. So, keeping IPv6 fragmentation
> around won't help very much.
>
> Ron
>
I don't 100% agree. In the case that PMTUD is broken, there'd be nothing
to stop a current DNSSEC implementation from always assuming a default
path MTU of 1280, without awaiting confirmation from PMTUD, and
fragmenting the UDP packet pre-emptively [assuming fragmentation was not
equally broken along the path as ICMP PTB was].

Looking at the opposite case [PMTUD OK, fragmentation deprecated] if
there's no fragmentation header available, what's the point of a stack
implementing PMTUD at the network layer (for UDP), when the only action
it could then take AFAICS is to punt to the application anyway?

BTW I'm not per se anti your draft. It's radical, but I'd like to
explore the pros and cons further before taking a position.

regards,
RayH
>
>
>
>
> Ray Hunter <mailto:[email-masked]>
> 21 June 2013 19:03
> ------------------------------------------------------------------------

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 21 Jun 2013 19:49:06 +0000

I suppose I'm the contrarian, but this draft gives me some heartburn surrounding the robustness principle. Yes, TCP MSS generally limits the use of fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and others have noted that OSPF etc may have issues. 

Thinking hypothetically, it would be unusual for OSPF to not be able to manage packet size via LSA choice, but suppose I am on an interface that has a given MTU, and I have a single LSA that is larger than that MTU, perhaps a Router LSA on a wide fan-out unit. Deprecating the fragmentation capability forces each client of the network layer to create a means for fragmentation/segmentation. That might be some other protocol that essentially duplicates what we're deprecating, or it could be something in which a router has to make enough routing instances of itself to split the Router LSA across them, or something like that.

Personally, I think I would prefer a statement that says that the first fragment MUST contain the transport header (which Fernando has been pushing), and encourages transports and applications to implement some variation on PMTU rather than depending on fragmentation, but not deprecating the capability.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Jun 2013 19:53:59 +0000

> I don't 100% agree. In the case that PMTUD is broken, there'd be
> nothing to stop a current DNSSEC implementation from always assuming a
> default path MTU of 1280, without awaiting confirmation from PMTUD, and
> fragmenting the UDP packet pre-emptively [assuming fragmentation was
> not equally broken along the path as ICMP PTB was].
> 

Do any implementations actually do this?

If they do, how well are they working, today?

                            Ron

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Jun 2013 08:52:46 +1200

> If they do, how well are they working, today?

Does it matter? Since we know that fragmentation is broken on some
paths due to broken firewalls, and that other paths have tunnels
on them, and that MSS negotiation fails on some paths, today's
sad reality is that the only safe link MTU for all times and places
is 1280.

I'm not yet convinced that deprecating fragmentation is sufficient
to fix this problem. In this case, not being sufficient might
also mean not necessary, so I'd like to see much more thorough
analysis across the IETF as a whole before reaching a conclusion.

(Thanks to the authors for coming out and saying it, though.)

   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Jun 2013 22:00:41 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, June 21, 2013 4:53 PM
> To: Ronald Bonica
> Cc: Ray Hunter; [email-masked] 6man-wg
> >> nothing to stop a current DNSSEC implementation from always assuming
> >> a default path MTU of 1280, without awaiting confirmation from
> PMTUD,
> >> and fragmenting the UDP packet pre-emptively [assuming fragmentation
> >> was not equally broken along the path as ICMP PTB was].
> >>
> >
> Does it matter? 

Hi Brian,

I think that it does. If a DNSSEC implantation fragments every packet larger than 1280 bytes, regardless of whether that packet needs to be fragmented:

- it ignores the advice of RFC 2460 and RFC 5405
- it doesn't work very well today, because so many operators filter its fragmented output

AFAIKS, there are two ways to make this application work better:

- make people stop filtering IPv6 fragments
- change the implementation's behavior

Given that the former is impossible, it seems that the later is required.

                               Ron

---

From: Tore Anderson <[email-masked]>
Date: Sat, 22 Jun 2013 11:29:04 +0200

* Ronald Bonica

> [draft-bonica-6man-frag-deprecate]

Being an operator I would definitively welcome getting rid of the
complexities dealing with IPv6 fragments bring. That said, the draft
needs additional discussion on this could be accomplished without
breaking assumptions made by other protocols, though.

On my network, I have two legitimate consumers of IPv6 fragments:

1) OSPFv3. RFC 2740 A.1 says «OSPF does not define a way to fragment its
protocol packets, and depends on IPv6 fragmentation when transmitting
packets larger than the link MTU». It does goes on to say «the OSPF
packet types that are likely to be large [...] can usually be split into
several separate protocol packets, without loss of functionality. This
is recommended; IPv6 fragmentation should be avoided whenever possible».
In my experience however, the implementation vendors appears to have
skipped over that last recommendation.

2) SIIT (RFC 6145). There are several corner cases where a SIIT
translator, or an IPv6 node communicating with an IPv4 node through such
a translator, have to deal with IPv6 fragments. In particular:

- When a SIIT translator receives an IPv4 packet with DF=0 that would
result in an IPv6 packet that would exceed the IPv6 link MTU, it will
split the original packet into IPv6 fragments.

- When a SIIT translator receives an IPv4 fragment, it will translate
this into one or more IPv6 fragments.

- When the SIIT translator receives an IPv4 packet with DF=0 it «SHOULD
always include an IPv6 Fragment Header to indicate that the sender
allows fragmentation». (I wouldn't miss this feature going away though,
as I disable it anyway.)

- When an IPv6 node receives an ICMPv6 Packet Too Big message indicating
a Path MTU less than 1280, it should either 1) simply heed the indicated
Path MTU, or 2) limit the size of subsequent transmitted packets to 1280
and include a Fragmentation header (w/MF=0, i.e., an "atomic" fragment)
in them. See RFC 2460 section 5. I know that Linux takes this second
approach, at least.

I cannot support your draft until it discusses or provides solutions for
the above considerations.

Finally I'll note that in all of the above cases, the use of IPv6
fragments is limited to within a single administrative domain (i.e., my
network), so the rationale that IPv6 fragmentation does not work over
the Internet does not really apply.

Best regards,
Tore Anderson

---

From: Mark Andrews <[email-masked]>
Date: Sun, 23 Jun 2013 12:49:05 +1000

In message <[email-masked]>, Ronald Bonica wri
> Given that the former is impossible, it seems that the later is required.

Named has set IPv6_USE_MIN_MTU for years for UDP.  There are plenty
of paths that have path mtu issues but not fragmentation issues
(tunnels).  Many firewalls allow fragments out but not icmp back in.

Named currently sets IPv6_USE_MIN_MTU for TCP.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 23 Jun 2013 23:01:51 +0000

Hi,

Deprecation of IPv6 fragmentation would make life difficult for IPv6
tunnels. For tunnels that span paths with ~1280 MTUs, the tunnel ingress'
only option is to fragment since it is not permitted to return a PTB with
MTU less than 1280. See RFC2473 for example of a normative specification
that depends on IPv6 fragmentation.

Thanks - Fred
[email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 23 Jun 2013 23:11:57 +0000

> split the original packet into IPv6 fragments.

It *could* fragment the IPv4 packet and send it in two unfragmented IPv6 packets.

> the above considerations.

I'm in a similar case with respect to protocols above IPv6 (OSPF and NFS/UDP come quickly to mind) that depend on fragmentation to deal with the issue. I think the Robustness Principle tells us that such applications SHOULD figure out how to live with PMTU, but it also tells us that we can't deprecate fragmentation unless all known instances that depend on it have defined practical work-arounds. I suspect that this would imply the re-creation of the fragmentation feature in an intermediate protocol, which seems like a lot of work with little real gain.

---

From: Glen Turner <[email-masked]>
Date: Mon, 24 Jun 2013 10:23:12 +0930

> I'm in a similar case with respect to protocols above IPv6 (OSPF and NFS/UDP come quickly to mind) that depend on fragmentation to deal with the issue. I think the Robustness Principle tells us tha…

Calculating the PMTU for UDP protocols is left to applications, the sockets API doesn't do this under the hood like it does for TCP. As a result most UDP-using applications don't probe the PMTU. This is the case for both IPv4 and IPv6, although the effect with IPv6 is lost connectivity rather than in-flight fragmentation.

Some small changes to the socket API for unconnected protocols would make life substantially better for RADIUS implementors (and, I imagine, DNS). We're more than happy to repeatedly pass the same application protocol data unit into the socket whilst the socket probes the path MTU.

-glen

---

From: George Michaelson <[email-masked]>
Date: Mon, 24 Jun 2013 10:59:58 +1000

Ron asserts the following two statements in this 00 draft:

     "..." As a result, IPv6 fragments carrying TCP payload are rarely
observed on the Internet.

and
     "..." Because many UDP-based applications follow the above-quoted
recommendation, IPv6 fragments carrying UDP traffic are also rarely
observed on the Internet.

I'd like to understand the basis of these assertions. I believe what I am
seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP
and UDP.

Ron also asserts:

  The following is a list of UDP-based applications that do not follow the
recommendation of [RFC5405]  and rely in IPv6 fragmentation:

   o  DNSSEC [RFC4035]

   The effectiveness of these protocols may currently be degraded by
operator behavior.  SeeSection 2.4 for details.

I'd like to point out that at least BIND imposes a 1280 IPv6 packet limit.
Its wired into the code.

-George

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Jun 2013 08:41:50 +1000

In message <[email-masked]>, "Fred Baker (fred)" writes:
> I suppose I'm the contrarian, but this draft gives me some heartburn surrounding the robustness principle. Yes, 
> TCP MSS generally limits the use of fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and othe
> rs have noted that OSPF etc may have issues. 
> 
> Thinking hypothetically, it would be unusual for OSPF to not be able to manage packet size via LSA choice, but s
> uppose I am on an interface that has a given MTU, and I have a single LSA that is larger than that MTU, perhaps 
> a Router LSA on a wide fan-out unit. Deprecating the fragmentation capability forces each client of the network 
> layer to create a means for fragmentation/segmentation. That might be some other protocol that essentially dupli
> cates what we're deprecating, or it could be something in which a router has to make enough routing instances of
>  itself to split the Router LSA across them, or something like that.
> 
> Personally, I think I would prefer a statement that says that the first fragment MUST contain the transport head
> er (which Fernando has been pushing), and encourages transports and applications to implement some variation on 
> PMTU rather than depending on fragmentation, but not deprecating the capability.

Or additionallty supply the information the firewall is looking for
in a skipable hop-by-hop option.  For UDP that would be the two
ports.  6 to 8 extra octets per fragment.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 24 Jun 2013 01:44:32 +0000

>Fred Baker (fred)
>Sent: Saturday, June 22, 2013 3:49 AM
>To: Ronald Bonica
>Cc: [email-masked] 6man-wg
>Subject: Re: New Version Notification for
>I suppose I'm the contrarian

+1. For me, this draft looks dangerous by proposing to deprecate fragmentation with only one-side observation. This draft does not give enough analysis on these existing fragmentation use cases, particularly these use cases the fragments within a single domain.

On other side , only disallowing fragmentation to be used among domains may helpful to reduce the operational complex.

Best regards,

Sheng

>but this draft gives me some heartburn
>surrounding the robustness principle. Yes, TCP MSS generally limits the use of
>fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and
>others have noted that OSPF etc may have issues.
>
>Thinking hypothetically, it would be unusual for OSPF to not be able to
>manage packet size via LSA choice, but suppose I am on an interface that has
>a given MTU, and I have a single LSA that is larger than that MTU, perhaps a
>Router LSA on a wide fan-out unit. Deprecating the fragmentation capability
>forces each client of the network layer to create a means for
>fragmentation/segmentation. That might be some other protocol that
>essentially duplicates what we're deprecating, or it could be something in
>which a router has to make enough routing instances of itself to split the
>Router LSA across them, or something like that.
>
>Personally, I think I would prefer a statement that says that the first fragment
>MUST contain the transport header (which Fernando has been pushing), and
>encourages transports and applications to implement some variation on

---

From: Doug Barton <[email-masked]>
Date: Sun, 23 Jun 2013 18:53:35 -0700

> (Thanks to the authors for coming out and saying it, though.)

Given that larger and faster pipes are becoming more common, and given 
that we know that larger packet sizes make for more efficient 
utilization of those pipes, IMO it's a really bad idea to "give up the 
fight" at this early stage in IPv6 deployment.

Until there is dramatic evidence to the contrary it seems to me that 
it's still worthwhile to push for making the protocol work as designed.

Doug

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 24 Jun 2013 02:19:06 +0000

I have the similar concern.
Especially in the softwire context, fragmentation is always an important consideration when developing various tunneling mechanisms.

B.R.
Bing

> Templin, Fred L
> Sent: Monday, June 24, 2013 7:02 AM
> To: Ronald Bonica
> Subject: RE: FW: New Version Notification for

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Jun 2013 13:09:39 +1000

> it's still worthwhile to push for making the protocol work as designed.

For DNS PMTUD is just too slow (TCP) or doesn't work (UDP) as the
servers don't keep query state to resend replies on ICMPv6 frag
required and client retries are just too slow to trigger the resend.
This is why I pushed for a way to say fragment at 1280 back in
'98[1] which became IPv6_USE_MIN_MTU[2].

A recursive server has around 3 seconds to do a DNS lookup before
the client gives up.  In that time it has to talk to multiple
servers.  Deal with dead servers.  Deal with packet loss due to
congestion.  Deal with broken servers that don't respond.  Deal
with PMTUD.  Deal with broken firewalls that don't pass fragments.

PMTUD can be eliminated by setting IPv6_USE_MIN_MTU.  This should
result in UDP fragments and TCP segments that don't get blocked due
to IP packet size.  Some TCP stacks are broken as IPv6_USE_MIN_MTU
is ignored when they do their MSS negotiation.

As far as I can see the main reason fragmentation becomes a issue
is that firewalls and load balancers can't determine what to do
with a fragment as some information from the L4 header is missing.
If we supply that information in every fragment as a hop-by-hop
option{s} most of the problems are addressed.

You still have some firewalls that want to do deep inspection of
the packet but even then they could reassemble after filtering based
on the hop-by-hop option{s} which would provide some protection to
the reassembly queues on the firewall.

I also don't see what the deep inspection of UDP/DNS packets is
trying to accomplish when the same firewall passes TCP/DNS messages
without reassembling them.  If you are a malicious server you would
just set TC=1 and attack the client over TCP.  Yes, most clients
do correctly handle TC=1.

Mark

[1] https://datatracker.ietf.org/doc/draft-ietf-ipngwg-bsd-frag/
[2] http://tools.ietf.org/html/rfc3542
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Mon, 24 Jun 2013 09:45:42 +0200

* Fred Baker (fred)

>> - When a SIIT translator receives an IPv4 packet with DF=0 that
>> would result in an IPv6 packet that would exceed the IPv6 link MTU,
>> it will split the original packet into IPv6 fragments.
> 

Wouldn't doing IPv4 fragmentation before translation to IPv6 be
logically identical to this other case I mentioned?

>> this into one or more IPv6 fragments.

I can't see how simply omitting the Fragmentation header in the IPv6
output could work here, as the node receiving those two unfragmented
IPv6 packets would see the first one containing a truncated L4 payload,
while the second one would be just garbage as it doesn't include a L4
header.

Tore

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Jun 2013 14:29:10 +0000

Tore,

Thanks for these very actionable comments. I will address them in the next draft version.

                           Ron

> From: Tore Anderson [mailto:[email-masked]]
> Sent: Saturday, June 22, 2013 5:29 AM
> To: Ronald Bonica
> 1) OSPFv3. RFC 2740 A.1 says <OSPF does not define a way to fragment
> its protocol packets, and depends on IPv6 fragmentation when
> transmitting packets larger than the link MTU>. It does goes on to say
> <the OSPF packet types that are likely to be large [...] can usually be
> split into several separate protocol packets, without loss of
> functionality. This is recommended; IPv6 fragmentation should be
> avoided whenever possible>.
> translator, or an IPv6 node communicating with an IPv4 node through
> such a translator, have to deal with IPv6 fragments. In particular:
> 
> - When the SIIT translator receives an IPv4 packet with DF=0 it <SHOULD
> allows fragmentation>. (I wouldn't miss this feature going away though,
> as I disable it anyway.)
> 
> - When an IPv6 node receives an ICMPv6 Packet Too Big message
> indicating a Path MTU less than 1280, it should either 1) simply heed
> the indicated Path MTU, or 2) limit the size of subsequent transmitted
> packets to 1280 and include a Fragmentation header (w/MF=0, i.e., an
> "atomic" fragment) in them. See RFC 2460 section 5. I know that Linux
> takes this second approach, at least.
> 
> I cannot support your draft until it discusses or provides solutions
> for the above considerations.
>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Jun 2013 14:48:14 +0000

> 
> +1. For me, this draft looks dangerous by proposing to deprecate
> fragmentation with only one-side observation. This draft does not give
> enough analysis on these existing fragmentation use cases, particularly
> these use cases the fragments within a single domain.
> 
> On other side , only disallowing fragmentation to be used among domains
> may helpful to reduce the operational complex.
> 

Sheng,

I hear you. The next version of the draft will include a discussion of SIIT, OSPFv3 and tunneling in general.

(This should address your comments, as well as those of Tore, Fred and Fred.)

                                  Ron

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Jun 2013 16:38:06 +0000

I'd like to understand the basis of these assertions. I believe what I am seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP and UDP.

Hi George,

It would be helpful if you could describe:

-          Where your observations are being made

-          What percentage of traffic is fragmented

-          What kinds of packets are being fragmented
                                                Ron

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 24 Jun 2013 16:50:04 +0000

> logically identical to this other case I mentioned?

Ah. You're correct. I was thinking about tunnels.

> while the second one would be just garbage as it doesn't include a L4

-----------------------------------
"We are learning to do a great many clever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

---

From: Ole Troan <[email-masked]>
Date: Mon, 24 Jun 2013 13:37:41 -0400

> On other side , only disallowing fragmentation to be used among domains may helpful to reduce the operational complex.

this draft should help us tease out answers to the question:
"if we wanted to deprecate IPv6 fragmentation, could we?"

then when we know the collateral damage, it will be easier to answer the other question:
"should we deprecate IP layer fragmentation or not".

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jun 2013 17:50:36 +0000

Hi Fred,

> Sent: Sunday, June 23, 2013 4:12 PM
> To: Tore Anderson
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
> 
> 
> I'm in a similar case with respect to protocols above IPv6 (OSPF and
> NFS/UDP come quickly to mind) that depend on fragmentation to deal with
> the issue. I think the Robustness Principle tells us that such
> applications SHOULD figure out how to live with PMTU, but it also tells
> us that we can't deprecate fragmentation unless all known instances
> that depend on it have defined practical work-arounds. I suspect that
> this would imply the re-creation of the fragmentation feature in an
> intermediate protocol,

That is essentially what SEAL does - it provides an intermediate-level
segmentation and reassembly capability that avoids the pitfalls of IP
fragmentation.

> which seems like a lot of work with little real gain.

It's not that bad, and IMHO worth it.

Thanks - Fred

---

From: Marc Lampo <[email-masked]>
Date: Mon, 24 Jun 2013 21:19:45 +0200

-1

Not because I'm a fan of fragmentation, but I think a layer 3 (IP) protocol
that does not support fragmentation should really be a *new* IP version.
In my opinion, the changes are too dramatic :
if layer 3, not supporting fragmentation, is asked to sent a message, too
big for one packet,
it should inform layer 4 with an error message;
while a layer 3 that supports fragmentation, can fragment and send in
multiple packets (and return succes to layer 4).

I can imagine case exist - without searching for explicit examples, some
already given or hinted at by others in this discussion -
where two partners in a conversation cannot communicate (perhaps only
simplex ?) because one is implemented
on a host that implements IPv6 with fragmentation and the other on a host
that implements IPv6 without fragmentation.

I do agree that fragmentation introduces attack vectors,
but allowing that hosts do not implement it is, for me, not the correct
approach.
I'd prefer to insist that all headers, up till and including the layer 4,
are in the first fragment
 and that implementations provide correct implementation of fragmentation.
(both suggestions merely a repetition of other contributors in this
discussion)

> - many firewalls, by default, block IPv6 fragments

I cannot comment on the first point.
My experience with enterprises is that firewalls used normally cope well
with fragments
 (in the sense that they can flow through)
 ((perhaps in the old days, before "stateful inspection", with basic ACL's;
   but even a cheap home router copes with (IPv4) fragmentation))
As for point 3 : when I look at firewall capabilities concerning IPv6
 I actually look if it is possible to allow *only* the fragmentation
extension header
 (as, in my opinion, it is the only extension header needed to let the
business run)
 ((a statement that, by itself, might generate discussion - please, in a
different thread))
So, as for the list of 3 points, I cannot support this "safe assumption".

Kind regards,

Marc

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Jun 2013 13:39:59 -0700 (PDT)

So I'm generally ok with it, more because I think a reasonable proportion of administers of the network are effectively deprecating features that rely on the network behaviour by prohibiting them.

I've noticed that a number of mechanisms have been developed for hosts to either more actively measure the capabilities of the network between the intended communications end points and then take action to overcome them (the variety of NAT traversal methods, ICMP-less PMTUD), or at least assume a limitation and take actions to overcome or avoid them (happy eyeballs, multipath TCP).

I think the rapid adoption of mobile multihomed hosts (i.e., smartphones and tablets) means that we will see hosts be smarter about these network limitations, because their connectivity to the network varies much more than it used to - they may have one or more connections to the network, and the quality and capability of those connections will vary. It seems as the network is ending up with more varying levels of "dumbness" (intentional or not), the hosts will get and are getting smarter.

Regards,
Mark.

>________________________________
> From: Marc Lampo <[email-masked]>
>To: Ronald Bonica <[email-masked]> 
>Cc: "[email-masked] 6man-wg" <[email-masked]> 
>Sent: Tuesday, 25 June 2013 5:19 AM
>Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
> 
>
>
>-1
>
>Not because I'm a fan of fragmentation, but I think a layer 3 (IP) protocol that does not support fragmentation should really be a *new* IP version.
>if layer 3, not supporting fragmentation, is asked to sent a message, too big for one packet,
>
>while a layer 3 that supports fragmentation, can fragment and send in multiple packets (and return succes to layer 4).
>
>
>I can imagine case exist - without searching for explicit examples, some already given or hinted at by others in this discussion -
>where two partners in a conversation cannot communicate (perhaps only simplex ?) because one is implemented
>
>on a host that implements IPv6 with fragmentation and the other on a host that implements IPv6 without fragmentation.
>
>
>
>but allowing that hosts do not implement it is, for me, not the correct approach.
>
>I'd prefer to insist that all headers, up till and including the layer 4, are in the first fragment
>
>(both suggestions merely a repetition of other contributors in this discussion)
>
>
>My experience with enterprises is that firewalls used normally cope well with fragments
>
> I actually look if it is possible to allow *only* the fragmentation extension header
>
> (as, in my opinion, it is the only extension header needed to let the business run)
>
> ((a statement that, by itself, might generate discussion - please, in a different thread))
>

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 24 Jun 2013 22:40:09 +0200

>- many firewalls, by default, block IPv6 fragments

One of my clients using extensive fragmentation features, their
application/transport layer is "build around" IPv6 fragmentation. Problem:
all components are hard wired in silicon, there is no change/modification
possible in the next decade.

I'm a little bit sad about this incompatible protocol change/break.
Fragmentation was an early design failure in IPv4 - for IPv6 fragmentation it
is still supported and I see no way to obsolete fragmentation without
incompatible protocol change. Especially "New IPv6 host implementations MAY
support IPv6 fragmentation and reassembly, but are not required to do so." and
"Network operators MAY filter IPv6 fragments.". - this break legacy
application/stacks using fragmentation.

Fragmentation is a nightmare for a middleboxes, no doubt and fragmentation was
an design failure. But fixing it in a incompatible manner is even worse. There
should never ever an protocol break.

Hagen

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 24 Jun 2013 22:52:27 +0200

>application/stacks using fragmentation.

Sidenote: packets are generated within a sensor network domain sending
fragmented packets via mcast to common PCs using general purpose OS (Windows,
Linux, ...).

"New IPv6 host implementations MAY support IPv6 fragmentation and reassembly"
break things. "New IPv6 host implementations MAY support IPv6 fragmentation
but MUST support reassembly" may superior. This will aging out fragmentation
over a longer period, new hosts will not use it but existing - applications will
not break.

"Network operators MAY filter IPv6 fragments." is a policy thing and costumers
have to deal with that already. So it is ok from my point of view.

Hagen

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Jun 2013 22:11:16 +0000

> break things. "New IPv6 host implementations MAY support IPv6
> fragmentation but MUST support reassembly" may superior. This will
> aging out fragmentation over a longer period, new hosts will not use it
> but existing - applications will not break.

I could live with this. Would it satisfy other folks' objections?

> 
> "Network operators MAY filter IPv6 fragments." is a policy thing and
> costumers have to deal with that already. So it is ok from my point of
> view.

Ack. It is a statement of fact, not an IETF imposed requirement.

                                 Ron

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Jun 2013 15:35:41 -0700

On Jun 24, 2013, at 15:11 , Ronald Bonica <[email-masked]> wrote:
>> 
>> "Network operators MAY filter IPv6 fragments."
> 

I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement.

>>  Updates: RFC 2460
>>  Intended status: Standards Track 
>>  [...]
>>  Requirements Language
>> 
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                                             ^^^^^
>>    document are to be interpreted as described in RFC 2119 [RFC2119].

>> 5. MAY  This word, or the adjective "OPTIONAL", mean that an item is
>>    truly optional.  One vendor may choose to include the item because a
>>    particular marketplace requires it or because the vendor feels that
>>    it enhances the product while another vendor may omit the same item.
>>    An implementation which does not include a particular option MUST be
                                                                   ^^^^
>>    prepared to interoperate with another implementation which does
>>    include the option, though perhaps with reduced functionality. In the
>>    same vein an implementation which does include a particular option
>>    MUST be prepared to interoperate with another implementation which
>>    does not include the option (except, of course, for the feature the
>>    option provides.)

This draft, if published with the precise wording I quoted above, would be IETF establishing a new requirement for IPv6 hosts to "be prepared to interoperate with" [network operators] that implement the option of dropping IPv6 fragments.

It's one thing for $ENTERPRISE to tell us that their network won't forward our IPv6 fragments.  In theory, that can be worked out under a bilateral agreement.  It's another thing entirely for IETF to tell everyone that our host implementations MUST be prepared to operate in networks that refuse to forward IPv6 fragments.  I have to assume that IPv6 Ready certification tests would be updated to validate conformance to this updated standard.

Please don't let anyone be confused about what is entailed for conformance to this update of RFC 2460.  This is quite a major change to the Internet Protocol Version 6.  I'm inclined to agree with other who say this proposal is so radical that it should warrant incrementing the major version number.

--
james woodyatt <[email-masked]>
core os networking

---

From: joel jaeggli <[email-masked]>
Date: Mon, 24 Jun 2013 16:12:46 -0700

> I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement.
If for whatever reason you're in the position to never actually look 
that far into the header why would you care?

---

From: james woodyatt <[email-masked]>
Date: Mon, 24 Jun 2013 17:04:09 -0700

On Jun 24, 2013, at 16:12 , joel jaeggli <[email-masked]> wrote:
> If for whatever reason you're in the position to never actually look that far into the header why would you care?

I have no idea what you're talking about.  Could you please elaborate?

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 25 Jun 2013 00:49:07 +0000

>(This should address your comments, as well as those of Tore, Fred and Fred.)

Hi, Ron,

Yes, this will address my comments. I agree with Ole that an analysis document would help us to understand the issues and the consequences.

However, I personally think we would found deprecating fragmentation in whole IPv6 protocol might be too dramatic and had too many incompatible issues after carefully and neutral analysis. The deprecating proposal by itself might create more problems than it fixes.

A compromise mechanism that only restrict the usage of fragmentation in certain scenarios may be much less damage.

Best regards,

Sheng

---

From: George Michaelson <[email-masked]>
Date: Tue, 25 Jun 2013 11:24:13 +1000

On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica <[email-masked]> wrote:

>    ** **
> and UDP.****
> ** **
> ** **
> Hi George,****
> ** **
> It would be helpful if you could describe:****
>
> ** **
>
> **-          **Where your observations are being made
>

On our own web services (www.apnic.net, and an associated whois service
which attracts more wide ranging traffic)

On 'high in the tree' DNS servers for reverse DNS, including an NS of
in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the
namespace being searched: we see queries over v6 transport to v4 domains,
and to ccTLD we secondary)

In a packet capture of 2400::/12 run in conjunction with Merit, as research
into darknets.

> ****
>
> **-          **What percentage of traffic is fragmented
>

our own web: practically none.

our own dns: 0.01%. in a sequence of 10 minute samples. consistently, I
might add.

the 2400::/12:  around 0.25% to 1%. so more variable, but higher.

> ****
>
> **-          **What kinds of packets are being fragmented
>

our own DNS: port 53. little TCP.

2400::/12 capture. mostly port 53. TCP doesn't get captured in the darknet
research. Its impossible to establish the end-to-end relationship.

I am not sure I call up to 1% of something 'rare'. I'm not even sure I call
0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 adoption rates are
at this class of deployment by end user, perhaps it also should be
considered for deprecation..

It really would be helpful to understand your assertion about the rarity of
IPv6 fragmentation. I want to understand how you got to this point of view
on IPv6 frags.

-George

****
> ****
>                                                 Ron****
> ** **

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jun 2013 11:53:17 +1000

In message <CAKr6gn2zu2n-pJMirG-seN5WX=[email-masked]>
, George Michaelson writes:
> --===============4023034923616370839==
> Content-Type: multipart/alternative; boundary=047d7b86e55011538004dff06308
> 
> --047d7b86e55011538004dff06308
> Content-Type: text/plain; charset=ISO-8859-1
> 

.58% of my IPv6 traffic in fragmented.  Assuming that it is mostly UDP I
get 14% of my IPv6 UDP traffic is fragmented.  Most of that traffic
is non local.  I would assume most of the drops are due to PMTUD
blocking the initial fragment but letting the tail fragment through
as this machine is behind a tunnel.

Mark

ip6:
	381915 total packets received
	0 with size smaller than minimum
	0 with data size < data length
	0 with bad options
	0 with incorrect version number
	2213 fragments received
	0 fragments dropped (dup or out of space)
	48 fragments dropped after timeout
	0 fragments that exceeded limit
	1077 packets reassembled ok
	217810 packets for this host
	0 packets forwarded
	93958 packets not forwardable
	0 redirects sent
	297719 packets sent from this host
	0 packets sent with fabricated ip header
	0 output packets dropped due to no bufs, etc.
	5031 output packets discarded due to no route
	33 output datagrams fragmented
	66 fragments created
	0 datagrams that can't be fragmented
	0 packets that violated scope rules
	93924 multicast packets which we don't join
	Input histogram:
		hop by hop: 132
		TCP: 202894
		UDP: 15103
		fragment: 2213
		ICMP6: 161573

---

From: joel jaeggli <[email-masked]>
Date: Mon, 24 Jun 2013 18:58:49 -0700

> I have no idea what you're talking about.  Could you please elaborate?
if you have a device that does not need to look beyond the 40 byte fixed 
header to forward then finding the frag header is additional work.

somewhat closer to the edge of the network I need to find the L4 header. 
but if you can't ( or don't want to look beyond the fixed header you 
probably shouldn't have to. insuring no fragmentation header exists 
implies further parsing of the header chain.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 25 Jun 2013 02:22:31 +0000

Hi Mark,

Thanks for this good empirical data!

I would like to verify your assertion that most of the IPv6 fragment carry UDP. Do you have any way to be sure?

                                      Ron

> From: Mark Andrews [mailto:[email-masked]]
> Sent: Monday, June 24, 2013 9:53 PM
> To: George Michaelson
> Cc: Ronald Bonica; [email-masked] 6man-wg
> > > I'd like to understand the basis of these assertions. I believe
> what
> > > I am seeing, on the edge, suggests there is in fact V6
> fragmentation
> > > in both TCP and UDP.****
> > >
> > > ** **
> > >
> > > ** **
> > >
> > > Hi George,****
> > >
> > > ** **
> > >
> > On our own web services (www.apnic.net, and an associated whois
> > service which attracts more wide ranging traffic)
> >
> > namespace being searched: we see queries over v6 transport to v4
> > domains, and to ccTLD we secondary)
> >
> > In a packet capture of 2400::/12 run in conjunction with Merit, as
> > research into darknets.
> >
> >
> > > ****
> > >
> > our own dns: 0.01%. in a sequence of 10 minute samples. consistently,
> > I might add.
> >
> > 2400::/12 capture. mostly port 53. TCP doesn't get captured in the
> > darknet research. Its impossible to establish the end-to-end
> relationship.
> >
> > I am not sure I call up to 1% of something 'rare'. I'm not even sure
> I
> > call 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6
> adoption
> > rates are at this class of deployment by end user, perhaps it also
> > should be considered for deprecation..
> >
> > IPv6 fragmentation. I want to understand how you got to this point of
> > view on IPv6 frags.
> >
> > -George
> 
> .58% of my IPv6 traffic in fragmented.  Assuming that it is mostly UDP
> I get 14% of my IPv6 UDP traffic is fragmented.  Most of that traffic
> blocking the initial fragment but letting the tail fragment through as
> this machine is behind a tunnel.
> 
> Mark
> 
> ip6:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jun 2013 14:39:24 +1200

> I could live with this. Would it satisfy other folks' objections?

I think it's far too soon in developing the analysis to be able
to answer that question. This isn't cooked yet.

> Ack. It is a statement of fact, not an IETF imposed requirement.

If it's a statement of fact, it shouldn't use RFC 2119 language. It
should simply state the truth: "Network operators might filter IPv6 fragments."

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jun 2013 11:44:07 +0900

> should simply state the truth: "Network operators might filter IPv6

s/might/do/

---

From: joel jaeggli <[email-masked]>
Date: Mon, 24 Jun 2013 20:03:53 -0700

On 6/24/13 12:19 PM, Marc Lampo wrote:
> -1
>
> Not because I'm a fan of fragmentation, but I think a layer 3 (IP) 
> protocol that does not support fragmentation should really be a *new* 
> IP version.
imho in some respects this is simply closing the circle...

Intermediate hopes can't fragment in ipv6 leaving it the exclusive 
domain of endpoints. if the endpoints can't simply generate large 
datagrams at the ip layer then they have to fragment upper layer 
datagrams somewhere else.

I agree with Fred T that this is a particular problem with tunnels 
becuase the IP datagrams you're encapsulating will have to be fragmented 
in some fashion, alternatively  you really have to be able to rely on 
PMTUD work and frankly I'd really like to work becuase I think it's 
rather sad that MTUs <= 1500  are all we can expect  to support end-to-end.
> I can imagine case exist - without searching for explicit examples, 
> some already given or hinted at by others in this discussion -
> on a host that implements IPv6 with fragmentation and the other on a 
> host that implements IPv6 without fragmentation.
>
>
> On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jun 2013 14:02:06 +1000

In message <[email-masked]
> UDP. Do you have any way to be sure?

I've looked at packet traces in the past and the fragmented traffic
is UDP.  The box is running a validating recursive nameserver which
advertises a 4096 byte EDNS UDP buffer.  It draws in fragmented
traffic.  I can tell when there are out of order IPv4 fragments as
the NAT in front of it doesn't handle the case where the first
fragment received is not the initial fragment.

Whether you see fragmented traffic is very dependent upon what you
are doing, how things are configured and what the application layer
has learnt about the network characteristics.

There is a lot of potential fragmented traffic out there.

Mark

---

From: George Michaelson <[email-masked]>
Date: Tue, 25 Jun 2013 15:06:53 +1000

One thing I *strongly* agree with: the sentence at 2.2:

                  The effective MTU for IPv6 is 1280 bytes.

This is looking compellingly awful, but true to me. I think there is enough
pMTU breakage that its safer to MSS clamp down. The downside cost in
apparent efficiency has been beaten to death, its a non-issue for me right
now. We even see broken tunnel heads which report back with pMTU the size
of the *outer* packet shroud, so tell 1400 byte packets to resend at ...
1400 bytes. FAIL.

cheers

-George

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 25 Jun 2013 05:17:34 +0000

On Jun 24, 2013, at 5:49 PM, Sheng Jiang <[email-masked]> wrote:

> However, I personally think we would found deprecating fragmentation in whole IPv6 protocol might be too dramatic and had too many incompatible issues after carefully and neutral analysis.

That is consistent with my view, for reasons I have already stated.

> The deprecating proposal by itself might create more problems than it fixes.

Possibly.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Jun 2013 17:15:49 +1000

Hi,

We _are_ seeing IPv6 packet fragmentation in TCP over IPv6, and the causes are systematic, rather than random chance.

What is happening is that the client is behind some form of tunnel (MPLS) we _assume_. The server (FreeBSD recent version) is sitting with a MTU of 1500, as is the client.

The client opens 5 ports in parallel (possibly firefox???) The client makes a request down port 1, then, a little later, makes another request down port 2. The server sends large packets down the TCP session open to port 1.  A gateway on the path sends back an ICMP6 packet too big to the server for this TCP session, with a new MTU of 1492. The TCP session on port 1 now adjust its MSS to 1432 (=1492 - 60) and the server resends its set of data as a sequence of packets each of which is 1492 octets in size - all good, no fragmentation of TCP packets so far.

But then, on the session open to the client's port 2 the server assembles its set of packets for the second request to send to the client. The TCP session on the server which is bound to port 2 of the client is unaware of the MTU change (after all, the ICMP6 PTB message was directed to the TCP session that is bound to client port 1, not port 2), and the server's IPv6 driver gets a set of 1440 octet TCP payload packets to send to the client. But there is a data structure in the server (I think FreeBSD uses the routing table, but the FreeBSD folk probably know better than I do which internal table is used to cache path MTU data derived from ICMPv6 PTB messages) which says that for this IPv6 destination address the new MTU is not 1500, but is 1492. The IPv6 output driver now fragments the queued TCP packets to session connected to the client port 2 to send 2 packets for each single packet passed to it from the upper level TCP driver, and what heads onto the wire is a 1420 octet payload and a 20 octet payload, with IPv6 fragmentation set to bind them together.

As far as I can see this is not "bad" behaviour. The second session has not received it own ICMP6 packet too big, so this TCP session (and all other parallel TCP sessions) are unaware of the need to drop its MSS, and because of the cached per host entry with the new MTU the IP driver is aware that it cannot send these packets out without fragmentation. So the IP layer is aware of this lower path MTU and correctly fragments the TCP packet to ensure delivery. I don't believe this is a bug per se. I think its an unintended side effect of the way in which ICMP6 PTB messages are processed by the recipient.

How prevalent is this behaviour?

Well, how prevalent are browsers that open up parallel ports to the same destination?

Gee, with today's browsers just about everyone does this!

If you want to deprecate IPv6 fragmentation and still allow this form of parallel session behaviour to work rather than wedge, then the internal handling of ICMPv6 PTB messages in the host needs to be reworked as far as I can tell.

thanks,

   Geoff

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jun 2013 17:17:40 +1000

> > should simply state the truth: "Network operators might filter IPv6

Which would be a totally mis-leading statement.  "Some network operators
filter IPv6 fragments."

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jun 2013 18:09:20 +1000

In message <[email-masked]>, Geoff Huston write
s:
> Hi,
> 
> We _are_ seeing IPv6 packet fragmentation in TCP over IPv6, and the =
> causes are systematic, rather than random chance.
> 
> What is happening is that the client is behind some form of tunnel =
> (MPLS) we _assume_. The server (FreeBSD recent version) is sitting with =
> a MTU of 1500, as is the client.
> 
> The client opens 5 ports in parallel (possibly firefox???) The client =
> makes a request down port 1, then, a little later, makes another request =
> down port 2. The server sends large packets down the TCP session open to =
> port 1.  A gateway on the path sends back an ICMP6 packet too big to the =
> server for this TCP session, with a new MTU of 1492. The TCP session on =
> port 1 now adjust its MSS to 1432 (=3D1492 - 60) and the server resends =
> its set of data as a sequence of packets each of which is 1492 octets in =
> size - all good, no fragmentation of TCP packets so far.
> 
> But then, on the session open to the client's port 2 the server =
> assembles its set of packets for the second request to send to the =
> client. The TCP session on the server which is bound to port 2 of the =
> client is unaware of the MTU change (after all, the ICMP6 PTB message =
> was directed to the TCP session that is bound to client port 1, not port =
> 2), and the server's IPv6 driver gets a set of 1440 octet TCP payload =
> packets to send to the client. But there is a data structure in the =
> server (I think FreeBSD uses the routing table, but the FreeBSD folk =
> probably know better than I do which internal table is used to cache =
> path MTU data derived from ICMPv6 PTB messages) which says that for this =
> IPv6 destination address the new MTU is not 1500, but is 1492. The IPv6 =
> output driver now fragments the queued TCP packets to session connected =
> to the client port 2 to send 2 packets for each single packet passed to =
> it from the upper level TCP driver, and what heads onto the wire is a =
> 1420 octet payload and a 20 octet payload, with IPv6 fragmentation set =
> to bind them together.
> 
> As far as I can see this is not "bad" behaviour. The second session has =
> not received it own ICMP6 packet too big, so this TCP session (and all =
> other parallel TCP sessions) are unaware of the need to drop its MSS, =
> and because of the cached per host entry with the new MTU the IP driver =
> is aware that it cannot send these packets out without fragmentation. So =
> the IP layer is aware of this lower path MTU and correctly fragments the =
> TCP packet to ensure delivery. I don't believe this is a bug per se. I =
> think its an unintended side effect of the way in which ICMP6 PTB =
> messages are processed by the recipient.
> 
> Well, how prevalent are browsers that open up parallel ports to the same =
> destination?
> 
> If you want to deprecate IPv6 fragmentation and still allow this form of =
> parallel session behaviour to work rather than wedge, then the internal =
> handling of ICMPv6 PTB messages in the host needs to be reworked as far =
> as I can tell.
> 
> thanks,
> 
>    Geoff

Which probably is some of the cause of some of the fragements I am
seeing.  I went looking for just such behaviour on pages I normally
visit and saw the above behaviour.  Note this on only on the initial
page load.  On reload no fragmentation is seen which is to be expected.

Mark

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Jun 2013 11:38:23 +0300

Geoff,

> If you want to deprecate IPv6 fragmentation and still allow this form of parallel session behaviour to work rather than wedge, then the internal handling of ICMPv6 PTB messages in the host needs to…

I think it would be good to fix this even if we don't deprecate IPv6 fragmentation.

Bob

---

From: Glen Turner <[email-masked]>
Date: Tue, 25 Jun 2013 19:47:13 +0930 (CST)

> I think it would be good to fix this even if we don't deprecate IPv6 fragmentation.

What's this look like on the API side? You pass in a packet. Does the
socket block because there may a packet in parallel (and how does
the mechanism under the API know that)?  Is that better or worse
than fragmentation?

I think that FreeBSD has done the reasonable thing. Given that the API
has accepted the packet it is transmitting it using the most recent
information about the path, rather than transmitting it with high
odds of failure.

-- 
Glen Turner <http://www.gdt.id.au/~gdt/>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Jun 2013 20:44:09 +1000

> information about the path, rather than transmitting it with high

I also believe that FreeBSD has done the best it can, and reasonably so. It is debatable whether
a ICMP6 PTB message should apply to all currently open TCP sessions to the same destination, as
I wonder about multi-path TCP and path diversity here.

Geoff

---

From: Tore Anderson <[email-masked]>
Date: Tue, 25 Jun 2013 13:37:39 +0200

* George Michaelson

> This is looking compellingly awful, but true to me.

I believe this is a gross exaggeration. I'm running 1500 bytes MTU on
all the clients and servers in my network, and have yet to hear about
significant trouble (there have been a few, but no more than what I get
with IPv4 as well).

So to see if this was only me, I tried to do a simple" wget -6" of all
the URLs listed in the top 100 sites sorted by Alexa rank at
http://www.worldipv6launch.org/participants/?q=1 and looked at what TCP
MSS values I got back:

TCP MSS   Count
---------------
1212      2
1220      6
1380      6
1410      3
1416      1
1420      1
1436      1
1440      67
1460      1
Total     88

Only 9% were operating on the premise that «the effective MTU for IPv6
is [<=] 1280 bytes», while a clear majority of 77% were operating with
an MTU of [>=] 1500.

(I did not get exactly 100 successful TCP handshakes because some URLs
were down, some did not have an IPv6 address published in DNS, while on
the other hand some were giving me HTTP redirects, which results in
multiple handshakes.)

Tore

---

From: John Leslie <[email-masked]>
Date: Tue, 25 Jun 2013 08:55:32 -0400

+1

--
John Leslie <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 25 Jun 2013 16:27:57 +0000

Hi,

I just wanted to put out one thought. When talking about fragmentation
and reassembly, never say "always" and never say "never". It is true
that some routers are not well positioned to perform steady-state
fragmentation and reassembly but that does not mean that it should
"never" be used for any purposes.

"Fragmentation Considered Harmful" was a seminal work, but it fell into
the trap of making black-and-white statements about fragmentation and
reassembly that do not "always" hold in *all* contexts. IP provides:
1) routing, 2) addressing, 3) a best-effort delivery model, and 4) a
fragmentation and reassembly capability. Omitting 4) would leave us
with something other than IP.

Thanks - Fred

---

From: Christian Huitema <[email-masked]>
Date: Tue, 25 Jun 2013 16:36:51 +0000

> I also believe that FreeBSD has done the best it can, and reasonably so. It is debatable whether a ICMP6 PTB message should apply to all currently open TCP sessions to the same destination, as I wonder about multi-path TCP and path diversity here.

There are certainly different ways to implement that, without inserting a fragmentation header. For example, if the lower layer knows that the packet is too big, it could send the local equivalent of "ICMP too big" back to the TCP layer.

-- Christian Huitema

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Jun 2013 14:20:59 -0400

> should simply state the truth: "Network operators might filter IPv6 fragments."

You mean like http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 says?
"This memo provides observational evidence for the dropping of IPv6
   fragments along a significant number of paths, explores the
   operational impact of fragmentation and the reasons and scenarios
   where drops occur, and considers the effect of fragment drops on
   applications where fragmentation is known to occur, particularly
   including DNS."

It references: http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
(also a fun read).

W

--
"Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."

    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Jun 2013 14:56:37 -0400

Randy,

>> should simply state the truth: "Network operators might filter IPv6

would you be able to answer why and where?

cheers,
Ole

---

From: Brian Jones <[email-masked]>
Date: Tue, 25 Jun 2013 12:42:13 -0400

On Tue, Jun 25, 2013 at 12:27 PM, Templin, Fred L <[email-masked]
> wrote:

+1

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2013 04:42:12 +0900

> would you be able to answer why and where?

perceived, rightly or wrongly, as an attack vector.  they do similarly
for v4.  often at enterprise borders (hell, they filter 53/tcp), and
occasionally inter-isp.

in reality, you can not count on pmtud working, and don't bet your buns
on frags getting through.

randy

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Jun 2013 16:03:41 -0400

Randy,

> for v4.  often at enterprise borders (hell, they filter 53/tcp), and

I'm aware of the Enterprise borders, I was a bit more surprised at the inter ISP filtering.
with my user hat on, I'm not paying my ISP to drop my packets. ;-)
I understand why an ISP would filter ISPs towards its own infrastructure,
but what would be the reasoning for filtering fragments that it transits?

> on frags getting through.

right, so something has to change. if that's in-band MTU discovery for all L4 protocols, or if it is something else I don't know.

cheers,
Ole

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2013 05:13:54 +0900

> with my user hat on, I'm not paying my ISP to drop my packets. ;-)

then you don't believe in qos, eh?  's ok.  neither do i.  :)

> I understand why an ISP would filter ISPs towards its own
> infrastructure, but what would be the reasoning for filtering
> fragments that it transits?

reasoning?  you want reasoning?  stay away from ops.

> right, so something has to change. if that's in-band MTU discovery for
> all L4 protocols, or if it is something else I don't know.

ron has made one suggestion.  though brutal, its simplicity and its
recognition of reality appeal to me.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Jun 2013 13:35:14 -0700

Tore Anderson wrote:
> I believe this is a gross exaggeration. I'm running 1500 bytes MTU on all
the
> clients and servers in my network, and have yet to hear about significant
> trouble (there have been a few, but no more than what I get with IPv4 as
> well).

So what happens over the next 10 years as there is a mix of 1500 & 4k
systems? Or over the next 100 as the sizes continue to vary and routes flap
across an array of link sizes? Yes pmtud sorts out part of that, but does
tcp or the app need to become more dynamic about MSS changes during a
connection? Why? Just so people that want to use the hammer of 'no
fragments' are happy? Wouldn't it be better for everyone to actually solve
the only real problem, and simply require the L4 protocol be in the first
fragment? 

Short sighted myopia about a seriously outdated frame size should not drive
decisions about long term deployment of an emerging protocol. If the L4 is
in the first fragment, there are no other problems that need solving. If
reassembly resources are a challenge for boxes specifically designed to do
that, question why; but one could go further and require that the only
fragment allowed to be smaller than 1280 is the last fragment. That would
mitigate most of the resource-consumption-crafting nonsense.

Tony

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Jun 2013 07:30:21 +1000

Just a sample of traffic which has next header != {icmp6,tcp,udp}
from overnight.  The machine was suspended for around 6 hours.

Mark

% tcpdump -n -i en1 'ip6[6]' "!=" 6 and 'ip6[6]' '!=' 58 and 'ip6[6]' "!=" 17
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:52:49.861052 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 1957066089:1957067489, ack 2497112622, win 8211, options [nop,nop,TS val 1119549604 ecr 198228615], length 1400
17:52:49.861058 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:49.870759 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 4097604338:4097605738, ack 3676482518, win 8211, options [nop,nop,TS val 3406672242 ecr 198228624], length 1400
17:52:49.870861 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:49.906115 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 3561334378:3561335778, ack 2160043005, win 8211, options [nop,nop,TS val 1133407665 ecr 198228649], length 1400
17:52:49.906199 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.051608 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 2316478184:2316479584, ack 4079720301, win 8211, options [nop,nop,TS val 865809331 ecr 198228615], length 1400
17:52:50.051789 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.178615 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 1119549917 ecr 198228942], length 1400
17:52:50.178666 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.179830 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 1119549917 ecr 198228942], length 1400
17:52:50.179894 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.182340 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 3406672548 ecr 198228942], length 1400
17:52:50.182406 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.182930 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 3406672548 ecr 198228942], length 1400
17:52:50.183046 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.292666 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 1133408049 ecr 198229040], length 1400
17:52:50.292729 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.293216 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 1133408049 ecr 198229040], length 1400
17:52:50.293269 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.391938 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400
17:52:50.391944 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.392463 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400
17:52:50.392669 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.393168 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400
17:52:50.393407 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.393994 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400
17:52:50.394089 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.394688 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 865809667 ecr 198229139], length 1400
17:52:50.394697 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.395152 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 865809667 ecr 198229139], length 1400
17:52:50.395217 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.396701 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400
17:52:50.396800 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.397830 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400
17:52:50.397895 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.398402 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400
17:52:50.398459 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.399010 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400
17:52:50.399162 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.607636 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 9996:11396, ack 1, win 8211, options [nop,nop,TS val 1119550327 ecr 198229350], length 1400
17:52:50.609180 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.609505 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 11424:12824, ack 1, win 8211, options [nop,nop,TS val 1119550327 ecr 198229350], length 1400
17:52:50.609702 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.613027 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 12852:14252, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400
17:52:50.613095 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.613889 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 14280:15680, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400
17:52:50.614165 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.614665 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 15708:17108, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400
17:52:50.614905 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.615212 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 17136:18536, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400
17:52:50.615455 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.629914 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400
17:52:50.630027 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.631168 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400
17:52:50.631369 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.632230 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400
17:52:50.632348 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.632882 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400
17:52:50.633135 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.864705 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 9996:11396, ack 1, win 8211, options [nop,nop,TS val 865810124 ecr 198229581], length 1400
17:52:50.864769 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.865965 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 11424:12824, ack 1, win 8211, options [nop,nop,TS val 865810124 ecr 198229581], length 1400
17:52:50.866235 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.883550 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 12852:14252, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400
17:52:50.883564 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.883934 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 14280:15680, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400
17:52:50.884125 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.884744 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 15708:17108, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400
17:52:50.884814 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.885494 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 17136:18536, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400
17:52:50.885725 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.886132 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 18564:19964, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229583], length 1400
17:52:50.886616 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:50.887054 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 19992:21392, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229583], length 1400
17:52:50.887241 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.089406 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 21420:22820, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400
17:52:51.089596 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.089992 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 22848:24248, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400
17:52:51.090124 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.090587 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 24276:25676, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400
17:52:51.090808 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.091491 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 25704:27104, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400
17:52:51.091815 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.107807 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 27132:28532, ack 1, win 8211, options [nop,nop,TS val 865810362 ecr 198229830], length 1400
17:52:51.108014 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.108389 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 28560:29960, ack 1, win 8211, options [nop,nop,TS val 865810362 ecr 198229830], length 1400
17:52:51.108589 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.112032 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 29988:31388, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400
17:52:51.112039 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.112734 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 31416:32816, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400
17:52:51.112739 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.113331 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 32844:34244, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400
17:52:51.113376 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.114068 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 34272:35672, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400
17:52:51.114239 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.118589 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 35700:37100, ack 1, win 8211, options [nop,nop,TS val 865810370 ecr 198229832], length 1400
17:52:51.118596 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.119116 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 37128:38528, ack 1, win 8211, options [nop,nop,TS val 865810370 ecr 198229832], length 1400
17:52:51.119235 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.123112 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 38556:39956, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400
17:52:51.123242 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.123762 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 39984:41384, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400
17:52:51.123890 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.124392 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 41412:42812, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400
17:52:51.124493 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.125236 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 42840:44240, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400
17:52:51.125349 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.309557 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 44268:45668, ack 1, win 8211, options [nop,nop,TS val 865810562 ecr 198230033], length 1400
17:52:51.309602 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.310071 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 45696:47096, ack 1, win 8211, options [nop,nop,TS val 865810562 ecr 198230033], length 1400
17:52:51.310128 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.313615 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 47124:48524, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400
17:52:51.313686 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.314433 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 48552:49952, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400
17:52:51.314516 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.315002 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 49980:51380, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400
17:52:51.315112 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.316023 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 51408:52808, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400
17:52:51.316082 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.320310 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 52836:54236, ack 1, win 8211, options [nop,nop,TS val 865810570 ecr 198230035], length 1400
17:52:51.320317 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.320745 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 54264:55664, ack 1, win 8211, options [nop,nop,TS val 865810570 ecr 198230035], length 1400
17:52:51.320894 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.327384 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 55692:57092, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400
17:52:51.327442 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.328138 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 57120:58520, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400
17:52:51.328197 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.328724 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 58548:59948, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400
17:52:51.328785 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.329732 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 59976:61376, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400
17:52:51.329738 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.331214 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 61404:62804, ack 1, win 8211, options [nop,nop,TS val 865810585 ecr 198230055], length 1400
17:52:51.331335 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.334647 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 62832:64232, ack 1, win 8211, options [nop,nop,TS val 865810585 ecr 198230055], length 1400
17:52:51.334699 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.336451 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 64260:65660, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400
17:52:51.336511 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.337829 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 65688:67088, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400
17:52:51.338001 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.338441 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 67116:68516, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400
17:52:51.338630 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.339011 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 68544:69944, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400
17:52:51.339221 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.340045 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 69972:71372, ack 1, win 8211, options [nop,nop,TS val 865810594 ecr 198230056], length 1400
17:52:51.340159 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.340900 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 71400:72800, ack 1, win 8211, options [nop,nop,TS val 865810594 ecr 198230056], length 1400
17:52:51.341221 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.344948 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 72828:74228, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400
17:52:51.345017 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.345529 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 74256:75656, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400
17:52:51.345798 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.346156 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 75684:77084, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400
17:52:51.346416 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.347169 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 77112:78512, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400
17:52:51.347237 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.348336 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 78540:79940, ack 1, win 8211, options [nop,nop,TS val 865810602 ecr 198230065], length 1400
17:52:51.348396 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:51.348947 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 79968:81368, ack 1, win 8211, options [nop,nop,TS val 865810602 ecr 198230065], length 1400
17:52:51.350828 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:52.145234 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 11412:12812, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400
17:52:52.145609 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:52.146180 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 12840:14240, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400
17:52:52.146557 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
17:52:52.146947 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 14268:15668, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400
17:52:52.147254 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28)
18:07:13.332185 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:07:13.334532 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:07:13.338261 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:07:13.340579 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:07:13.537905 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:14:34.369295 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:40.235932 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
18:16:40.321234 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:40.323531 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:40.325932 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:40.734578 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
18:16:41.243931 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.246590 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.251308 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.346659 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.349150 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.351525 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.353840 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:41.756973 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
18:16:42.984622 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:42.989295 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.204949 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.290904 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.293616 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.599059 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.600358 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:43.705533 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:45.237348 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:16:45.749322 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:46:40.415607 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:46:40.416955 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:46:40.420216 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:46:40.424803 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
18:46:40.726339 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:49.576248 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:49.578604 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:47.772145 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:47.886129 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
19:15:48.079267 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:48.081514 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:48.387608 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
19:15:48.899441 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:48.901953 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.003082 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.007907 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.105533 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.107893 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.112726 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.412782 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
19:15:49.414144 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.416516 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:49.924607 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:50.844019 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:50.949711 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:51.356982 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:52.892870 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:15:53.404971 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:42:01.155878 IP6 2001:500:f::1 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1232) 53 > 58227: 4349*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
19:42:01.156074 IP6 2001:500:f::1 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1232|401)
19:57:15.894538 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:57:15.897083 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:57:15.899208 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:57:15.996810 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:57:16.405172 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:57:35.143376 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:56.483978 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
20:02:56.485356 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:56.491613 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:56.578470 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:56.988418 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
20:02:57.500075 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:57.601454 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:57.703891 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:58.013403 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
20:02:59.444688 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:59.548441 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:59.855470 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:59.857730 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:02:59.959986 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.163930 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.166387 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.487691 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.489211 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.491527 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:00.981709 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:01.596051 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:03:02.005761 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:32:56.875744 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:32:56.878014 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:32:56.880359 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:32:56.882750 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:32:56.979255 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:42:11.994105 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
20:42:13.318680 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
20:42:13.532224 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
20:50:34.875054 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:14:20.583254 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:14:21.584086 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:14:25.091410 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:14:26.595319 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:15:15.100274 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108
21:15:15.591888 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108
21:34:37.323302 IP6 2001:500:2c::254 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (0|1232) 53 > 51301: 50046*- 2/5/13 A 149.20.48.47, RRSIG (1224)
21:34:37.323529 IP6 2001:500:2c::254 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1232|398)
21:36:34.572006 IP6 2001:500:60::30 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (0|1232) 53 > 56840: 54055- 0/9/13 (1224)
21:36:34.572257 IP6 2001:500:60::30 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1232|379)
21:43:13.526347 IP6 2001:500:e::1 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1448|188)
21:47:58.614379 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:58.918080 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:58.919373 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.024058 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.027673 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.029022 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.030457 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.046346 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
21:47:59.430352 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.437089 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.442249 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.636019 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:47:59.740690 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.742069 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.746785 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:47:59.749210 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:00.046798 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
21:48:01.786421 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:02.093672 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:02.607743 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:02.612625 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:03.120620 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:12.336322 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:12.338697 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:12.559289 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:12.651572 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:12.662981 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.051988 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.356771 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.460406 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.463092 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.465456 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.592105 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.721509 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:13.722975 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
21:48:14.077058 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:17:58.503374 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:17:58.607065 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:17:58.609377 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:17:58.611831 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:17:58.617512 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:23:29.257394 IP6 2001:500:e::1 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1448|185)
22:31:19.889116 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:31:19.893077 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:34:46.586189 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
22:34:47.095108 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88
22:44:51.663691 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:51.667036 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:51.670728 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:51.878056 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:44:52.380588 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
22:44:52.893356 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:52.898210 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:52.902725 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:52.995006 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.004304 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.404716 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.408237 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
22:44:53.411976 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.414459 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.417055 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:53.918425 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:54.940413 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:54.946081 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:55.351141 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:56.887002 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
22:44:57.402222 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:06:04.659331 IP6 2001:500:b::1 > 2001:470:1f00:820:9418:8590:f473:f88f: frag (0|1232) 53 > 64255: 60624*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
23:06:04.659517 IP6 2001:500:b::1 > 2001:470:1f00:820:9418:8590:f473:f88f: frag (1232|401)
23:41:15.583240 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
23:41:16.084012 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
23:41:16.584356 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
23:41:17.585750 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:42:56.242973 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
23:42:56.746437 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
23:44:58.091635 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:44:58.094088 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:44:58.193844 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:44:58.196307 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:44:58.198648 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:44:58.604426 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
23:49:41.742371 IP6 2001:500:e::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1448|185)
00:00:08.776153 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:00:08.778492 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:01:47.801090 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 58283: 27824*- 2/5/13 A 149.20.64.50, RRSIG (1224)
00:01:47.801296 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|400)
00:01:47.801693 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 63408: 65514*- 2/5/13 AAAA 2001:4f8:0:2::29, RRSIG (1224)
00:01:47.801884 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|412)
00:05:20.906027 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:05:21.419808 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:05:22.335053 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:05:22.437494 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:09:48.890996 IP6 2001:500:f::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 64978: 69*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
00:09:48.891117 IP6 2001:500:f::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|401)
00:20:20.828198 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:20:21.332122 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
00:20:21.943663 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:22.354147 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:22.762869 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:22.765160 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:22.767603 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:22.774397 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:23.889222 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:23.891529 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:24.299810 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:25.835941 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:26.347892 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:32.905387 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:32.907790 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
00:20:32.910144 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
06:33:09.151217 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
06:33:09.651534 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
06:33:10.654793 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
06:38:25.162471 IP6 2001:500:e::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|185)
06:38:26.394389 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55664: 53890*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
06:38:26.394602 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401)
06:39:09.610324 IP6 2001:500:1b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51395: 64701*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
06:39:09.610497 IP6 2001:500:1b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|405)
06:39:22.148032 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62347: 55919*- 2/5/13 A 149.20.64.69, RRSIG (1224)
06:39:22.148144 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395)
06:39:22.148659 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51055: 41711*- 2/5/17 MX mx.pao1.isc.org. 10, RRSIG (1224)
06:39:22.149018 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|791)
06:39:25.371843 IP6 2001:660:3003:2::4:1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64760: 35070*- 6/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
06:39:25.371971 IP6 2001:660:3003:2::4:1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|247)
06:40:07.150343 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55392: 61643*- 2/5/13 TXT "dkim=unknown", RRSIG (1224)
06:40:07.150557 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|421)
06:40:36.902005 IP6 2001:500:71::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51811: 30400*- 2/5/13 A 149.20.64.69, RRSIG (1224)
06:40:36.902182 IP6 2001:500:71::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395)
06:40:55.571251 IP6 2620::630:4000:164:62:13:3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|64) 53 > 56429: 41844*- 5/0/1 DNSKEY[|domain]
06:40:55.572986 IP6 2620::630:4000:164:62:13:3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (64|1400)
06:40:56.055758 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 59233: 54142*- 4/5/15 CNAME ftc.gov., RRSIG, A 164.62.13.221, RRSIG (1224)
06:40:56.056230 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|1232)
06:40:56.056542 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (2464|784)
06:41:32.449694 IP6 2001:418:1::39 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62253: 41728*- 2/4/13 MX psg.com. 0, RRSIG (1224)
06:41:32.449785 IP6 2001:418:1::39 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|366)
06:41:38.714849 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 53495: 11304*- 2/5/13 A 149.20.64.69, RRSIG (1224)
06:41:38.714971 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395)
06:42:18.992934 IP6 2400:8900::f03c:91ff:feae:2d4b > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (2896|236)
06:44:08.326550 IP6 2001:500:27::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62103: 29552*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
06:44:08.326610 IP6 2001:500:27::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|397)
06:44:13.380727 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 52690: 18373*- 2/5/13 A 149.20.64.69, RRSIG (1224)
06:44:13.380959 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395)
06:44:13.415412 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 56045: 29309*- 2/5/13 TXT "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x1EKBg6oaur3iEUtMjFolpkY" "CAjkUmGZ9zIqVQtEfpiGzceu3ZXh3pp2+EnJBD8y4Uiyi9zqQm/y871jJRcUvwUv" "R2Sxd5pyaRMeVyfiR/LChaY+ukPoDGDsT/XnZfdYipTtzZteiOhVst4rqBLF09zL" "no5EbG86nGTpMGEvoQIDAQAB", RRSIG (1224)
06:44:13.415630 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|650)
06:45:22.523759 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64796: 23978*- 2/5/13 A 149.20.64.69, RRSIG (1224)
06:45:22.525115 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395)
06:46:34.353865 IP6 2001:558:100a:5:68:87:68:244 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423)
06:46:35.481840 IP6 2001:558:100e:5:68:87:72:244 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423)
06:46:36.486151 IP6 2001:558:1004:7:68:87:85:132 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423)
06:46:37.692618 IP6 2001:558:fe23:8:69:252:250:103 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423)
06:46:38.560072 IP6 2001:558:1014:c:68:87:76:228 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423)
06:57:04.886209 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64098: 49357*- 2/5/13 A 149.20.64.52, RRSIG (1224)
06:57:04.886422 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400)
06:57:04.889513 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64425: 27429*- 2/5/13 AAAA 2001:4f8:0:2::31, RRSIG (1224)
06:57:04.889767 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|412)
06:57:07.775639 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 63512: 59048*- 2/5/13 AAAA 2001:4f8:0:2::29, RRSIG (1224)
06:57:07.775644 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|412)
06:57:07.775645 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 60471: 18408*- 2/5/13 A 149.20.64.50, RRSIG (1224)
06:57:07.775646 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400)
06:57:31.164959 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 54190: 24114*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
06:57:31.165074 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401)
06:57:38.876542 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|453)
06:57:38.881370 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|453)
06:57:39.976325 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 50400: 23372*- 3/5/10 CNAME www.glb.nist.gov., RRSIG, RRSIG (1424)
06:57:39.976517 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|453)
06:57:39.978375 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 53127: 36865*- 3/5/10 CNAME www.glb.nist.gov., RRSIG, RRSIG (1424)
06:57:39.978527 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|453)
06:57:40.308244 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 63791: 29216- 0/5/10 (1424)
06:57:40.308370 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|99)
06:57:40.308712 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 65418: 62337- 0/5/10 (1424)
06:57:40.308929 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|99)
07:01:19.568135 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 50444: 34759*- 2/5/13 A 149.20.0.20, RRSIG (1224)
07:01:19.568305 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400)
07:01:40.447897 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55785: 10694*- 2/5/13 A 149.20.64.74, RRSIG (1224)
07:01:40.448025 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|399)
07:01:40.453161 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 61252: 62748*- 2/5/13 AAAA 2001:4f8:0:2::22, RRSIG (1224)
07:01:40.453409 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|411)
07:01:41.790461 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 63120: 45424*- 2/5/13 A 149.20.48.47, RRSIG (1224)
07:01:41.790601 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|398)
07:02:43.711442 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 58854: 24002*- 2/5/13 A 149.20.48.19, RRSIG (1224)
07:02:43.711667 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|404)
07:02:43.713360 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 57699: 25653*- 2/5/13 AAAA 2001:4f8:3:d::19, RRSIG (1224)
07:02:43.713598 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|416)
07:20:54.992739 IP6 2001:500:f::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 52860: 23762*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
07:20:54.992950 IP6 2001:500:f::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 25 Jun 2013 22:30:32 +0000

The case usually mentioned is in firewalls, under a policy that targets reassembly attacks. If system A sends a fragment but not all fragments of a message to system B, some of system B's resources are consumed until a timeout-or-something occurs. Dropping fragments prevents that.

Personally, I think the right solution is not to drop fragments, but impose limits on storage for reassembly. Fragments arriving in B should consume at most some amount of storage for some amount of time; if the time elapses, one discards the stale fragments, and if a new fragment arrives when resources are maxed out, one discards the oldest fragment present (LRU). We can argue ad infinitum on the amount of storage and time; I actually don't think the exact numbers are important. The time should be some multiple of the largest RTT the system sees, which is probably on the order of hundreds of milliseconds to seconds, and the storage quantum that is reasonable is probably measured in kilobytes. Beyond orders of magnitude, it's cook's choice.

Listing the folks that have that firewall rule - I can't say. There seems to be a widely-held belief that the people exist.

---

From: james woodyatt <[email-masked]>
Date: Tue, 25 Jun 2013 16:08:49 -0700

> recognition of reality appeal to me.

Why not go large and deprecate all of RFC 2460?

I'm not entirely joking.  If the practical global MTU for IPv6 is 1280, and while the practical global MTU for IPv4 remains larger, then I would say that pretty much serves as a guarantee that the transition from IPv4 to IPv6 cannot ever be successful.  It will always be the case that IPv4 is a better outer encapsulation that IPv6 for whatever overlay network succeeds as the next L3 protocol standard.

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2013 08:23:10 +0900

> while the practical global MTU for IPv4 remains larger, then I would
> say that pretty much serves as a guarantee that the transition from
> IPv4 to IPv6 cannot ever be successful.

i had a semi-discussion with olaf kolkman, who was saying dnssec and
ipv6 were slow and steady transitions.  i pointed out that dnssec, with
all its warts, was forward compatible and there was no visible
alternative.  ipv6, otoh, is incompatible on the wire and to the user,
and there are viable, though disgusting, alternatives, nat.

i am not optimistic.  in our second system syndrome religious ferver, we
have left the customer behind.  if we have any last chance, it is to
make it as absolutely easy as possible for folk running ipv4 to add
ipv6, no excuses, no self-righteous crap, no ivory tower.  all speed
bumps must br removed.

st00pid terribly trivial example.  why do i have to install a second
dhcp server for v6?  why does the default one not do both?  so building,
testing, installing, dhcpv6 goes on the enterprise's mess of a ipv6
transition pert chart and the perceived cost goes up.  and no, dhcp-
based enterprises are not gonna transition to stateless, i said no
religion.

ron is actually deploying ipv6 in enterprises to see what his customers
are seeing, eating his own dogfood.  he did not field this draft for his
amusement or to get his name on an rfc.

randy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Jun 2013 09:37:16 +1000

> mitigate most of the resource-consumption-crafting nonsense.

One needs to get the L4 information the firewall/loadbalancer uses
in *each* fragment.

For UDP this is the source and destination ports.  Create a new
skipable hop-by-hop option that contains a copy of these values and
add it along with a fragment header when fragmenting UDP packets.

For TCP ensure that the IP layer informs the TCP layer if it would
have to fragment the packet. i.e. don't send fragmented TCP packets.

For ICMPv6 ???

For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 packets
destination reassembles.
For IPv4 if DF=1 return IPv4 PTB

For XXX ????

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2013 11:48:38 +1200

On 26/06/2013 11:08, james woodyatt wrote:
> I'm not entirely joking.  If the practical global MTU for IPv6 is 1280, ...

We went through a protracted phase where the practical global MTU
for IPv4 was around 512, unless you wanted to reconfigure your laptop
stack experimentally each time you checked into a hotel and figured
out how to connect to the phone line. I even recall having to set the
MTU to 256 in one hotel. We may well have to accept a protracted phase
of 1280 for IPv6. Eventually it will resolve itself, as it did for IPv4.
I think that's orthogonal to the question of deprecating L3 fragmentation.

    Brian

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Jun 2013 09:53:06 +1000

If the recommended MTU was dropped, the frag changes probably wouldn't be
needed.

If the recommended MTU was dropped, could we raise the recommended MTU
again later, on some evidence based process to confirm how its working?

If this was only a recommendation, would it be enough? No code changes
required: totally in the hands of operators and host configuration. Can be
done on BSD and Linux systems trivially.

APNIC has been running some of its web services on a dropped MTU for some
time. It definitely reduced the incidence of pMTU related fail-to-fetch
over V6 which we were seeing. (a bunch of people in Europe were seeing this
facing us. We have seen this facing sites like ISOC and the IETF, in times
past, as a result of dual-stacking)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2013 11:57:41 +1200

On 26/06/2013 11:23, Randy Bush wrote:
...

> amusement or to get his name on an rfc.

The only times I've seen hard FAILs with apparently operational IPv6
sites were caused by MTU mismatch and TCP MSS negotiation failure,
followed by silence which I assumed was due to fragmented packets
being discarded. Yes, this is a real problem and doing nothing
certainly isn't an option. We just need to be sure that the cure
isn't worse than the illness.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Jun 2013 10:06:45 +1000

> isn't worse than the illness.

Named uses IPV6_USE_MIN_MTU=1 to avoid this.  It should affect MSS
negotiation but MacOS and FreeBSD are broken (bug fix submitted for
FreeBSD).

Mark

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 25 Jun 2013 17:49:32 -0700

On Tue, 25 Jun 2013 16:36:51 +0000

> There are certainly different ways to implement that, without inserting a fragmentation header. For example, if the lower layer knows that the packet is too big, it could send the local equivalent…

This certainly seems like a bug, no matter how you slice it:

* If the implementation wanted to allow for different MTUs on a per-flow
  basis (reasonable given the prevalence of NATs), it should go ahead 
  and send a full-sized packet for the second flow, and find out what
  the MTU is.

* If the implementation wanted to efficiently use the first Packet Too
  Big it got to fix all possible flows, TCP should re-segment the data
  in the second flow, rather than allowing fragmentation.

I can't think of a case in which it would be better for TCP to fragment
rather than re-segment (since it's a lot more efficient to recover from
a dropped segment than a dropped fragment), but I'm sure I will as soon
as I hit send.

Kevin
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 25 Jun 2013 17:57:05 -0700

Mark Andrews wrote:
> One needs to get the L4 information the firewall/loadbalancer uses in
*each*
> fragment.

This is a manufactured requirement to allow devices that can't do a full
reassembly to operate in under a policy of 'verify the entire packet'.
Unfortunately, it doesn't even do that since it doesn't actually detect
overlapping fragments if it is just verifying that the L4 information is the
same. 

Load balancers just need to get over it, and use something more/other than
the L4 in the hash. The FL was intended to provide a consistent value over
the life of an L4 session, so why not use that instead of developing yet
another new option? Wait,,, that doesn't exist in IPv4, so it can't be used
because that would require learning something different...

> For UDP this is the source and destination ports.  Create a new skipable
hop-
> by-hop option that contains a copy of these values and add it along with a
> fragment header when fragmenting UDP packets.

I have no problem with that concept, but why when there are other ways of
accomplishing the task? Simply to mirror IPv4 is not a valid reason...

> 
> For TCP ensure that the IP layer informs the TCP layer if it would have to
> fragment the packet. i.e. don't send fragmented TCP packets.

So TCP is never allowed to have a long-lived session ... Or routes are not
allowed to flap. Which is it? You either tear down tcp and renegotiate mss
every time routes flap to a path with a lower mtu, or you send fragments. It
is easy to say the core is >=1500 now, but what happens with a mix of
1500/4k/9k/32k/... over the life of IPv6? Are routes never allowed to flap
with larger MTUs? Do you require every TCP implementation to do dynamic MSS,
and try to get that deployed within a decade to two?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Jun 2013 11:38:04 +1000

> overlapping fragments if it is just verifying that the L4 information is the

Many firewalls are just trying to ensure packets match the <protocol,
src address, src port, dest address, dest port> tuple.  They are
not trying to protect from overlapping fragements.

That said being able to filter out / forward without reassembly
fragments that you are not interested in also reduces the number
of fragments that need to be processed in the reassembly queues of
the firewall itself when you are doing dpi of some of the packets.

> because that would require learning something different...

Flow labels aren't a solution for all problems.  Yes, load balancers should
make use of them.

> accomplishing the task? Simply to mirror IPv4 is not a valid reason...

It isn't just mirror IPv4.
 
> So TCP is never allowed to have a long-lived session ...

No.  It's send the equivalent of PTB back to the TCP layer and have
it re-segment rather than fragment a badly sized segment it passed
to the IP layer.  You have a broken stack if you see a TCP fragment.

> Or routes are not

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Jun 2013 02:17:30 +0000

>Personally, I think the right solution is not to drop fragments, but impose
>limits on storage for reassembly. 

+1. Also some operation or implementation recommendations, which try to limit the usage of fragment in certain scenarios, may be helpful.

Sheng

>Fragments arriving in B should consume at
>most some amount of storage for some amount of time; if the time elapses,
>one discards the stale fragments, and if a new fragment arrives when
>resources are maxed out, one discards the oldest fragment present (LRU). We
>can argue ad infinitum on the amount of storage and time; I actually don't
>think the exact numbers are important. The time should be some multiple of
>the largest RTT the system sees, which is probably on the order of hundreds
>of milliseconds to seconds, and the storage quantum that is reasonable is
>probably measured in kilobytes. Beyond orders of magnitude, it's cook's
>choice.
>
>Listing the folks that have that firewall rule - I can't say. There seems to be a
>widely-held belief that the people exist.
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 26 Jun 2013 03:30:07 +0000

On Jun 25, 2013, at 12:42 PM, Randy Bush <[email-masked]> wrote:

> in reality, you can not count on pmtud working

One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't implement RFC 4821.

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2013 13:33:45 +0900

> don't implement RFC 4821.

router code has also been problematic.  a mess.  but i do not harbor the
fantasy that it will be fixed.  i might wish it, but i don't expect it.

randy

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 26 Jun 2013 03:56:47 -0700 (PDT)

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: Randy Bush <[email-masked]>
> Cc: IPv6 Deployment Prevention <[email-masked]>
> Sent: Wednesday, 26 June 2013 1:30 PM
> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't 

Actually, Linux does, it just needs to be switched on in /proc/sys/net/ipv4/
tcp_mtu_probing - INTEGER Controls TCP Packetization-Layer Path MTU Discovery.  Takes three values: 0 - Disabled 1 - Disabled by default, enabled when an ICMP black hole detected 2 - Always enabled, use initial MSS of tcp_base_mss.
I think Windows also implements something similar:
"
Troubleshooting PMTU Black Hole Routers"
http://technet.microsoft.com/en-us/library/cc958871.aspx

One of the issues with conventional ICMP PTB based PMTUD is the default rate limits on ICMP messages on broadband routers with PPPoE subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD. Upping the limit on ICMP PTBs is an obscure parameter to have to remember to change, and it isn't clear exactly what to change it to - IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821 would be nice because it would avoid control plane processing that ICMP based PMTUD causes.

Regards,
Mark.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 26 Jun 2013 15:46:25 +0000

On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith <[email-masked]> wrote:
>> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
>> 

In other words, it's not on. There is some dead code there, but unless you are the writer of the application or a Linux techie, it doesn't work for you.

> http://technet.microsoft.com/en-us/library/cc958871.aspx

"To respond effectively to black hole routers, you must enable the Path MTUBH Detect feature of TCP/IP."

In other words, it's not on. There is some dead code there, but unless you are the writer of the application or a Windows techie, it doesn't work for you.

My question isn't whether there is some experimental code somewhere that could possibly implement it if someone rewrote the application or did some surgery in the system's configuration files. If my daughter bought a standard system and started using it, would it work for her? My question is why folks aren't implementing it in the normal case. Experimental code is kind of pointless in the general case.

> One of the issues with conventional ICMP PTB based PMTUD is the default rate limits on ICMP messages on broadband routers with PPPoE subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down P…

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 26 Jun 2013 22:22:05 +0200

>negotiation but MacOS and FreeBSD are broken (bug fix submitted for

problem report number or link into GNATS database?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Jun 2013 07:52:51 +1000

> problem report number or link into GNATS database?

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173444

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Jun 2013 01:52:43 +0200

On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote:
> 
> One of the issues with conventional ICMP PTB based PMTUD is the
> default rate limits on ICMP messages on broadband routers with PPPoE
> subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD.
> Upping the limit on ICMP PTBs is an obscure parameter to have to
> remember to change, and it isn't clear exactly what to change it to -
> IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821
> would be nice because it would avoid control plane processing that
> ICMP based PMTUD causes.

Many implementers don't want to rely on a 100% ICMP-less PMTUD because
of the potentially-lng convergence time (i.e. time to discover the PMTU).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Jun 2013 17:39:27 -0700

>> in reality, you can not count on pmtud working

In reality, you can not count on the Internet working.  Despite that, it mostly works, most everywhere you need it to work, most of the time.  Only occasionally, does one encounter failure.

> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't implement RFC 4821. 

One of these days, I'll understand why operators don't make it MANDATORY for all hosts on their networks to implement RFC 4821 before they configure their routers to break ICMPv6 path MTU discovery.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Jun 2013 11:04:24 +1000

In message <[email-masked]>, james woodyatt writes:
> In reality, you can not count on the Internet working.  Despite that, it mostly works, most everywhere you need it to wor
> k, most of the time.  Only occasionally, does one encounter failure.
> 
> One of these days, I'll understand why operators don't make it MANDATORY for all hosts on their networks to implement RFC
>  4821 before they configure their routers to break ICMPv6 path MTU discovery.

I don't know why firewall vendors permit configurations that block
icmpv6 PTB while passing ipv6 packets bigger than 1280 over the same
interface.  Such a configuration is broken.

If you don't want to let icmpv6 PTB in then set the MTU to 1280 and
generate icmpv6 PTB for anything bigger than 1280 yourself.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2013 13:14:12 +1200

Cutting to the chase, and assuming that the next version
will have more analysis and observational evidence, I'm thinking
something like the following:

3.  Recommendation

   This memo deprecates IPv6 fragmentation and the IPv6 fragment header.
   Application and transport layer protocols SHOULD support effective
   PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981]
   is unreliable. Any application or transport layer protocol that
   cannot support effective PMTU discovery MUST NOT in any circumstances
   send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes.

   IPv6 stacks and forwarding nodes SHOULD continue to support inbound
   fragmented IPv6 packets as specified in [RFC2460]. However, this
   requirement exceeds the capability of some types of forwarding node
   such as firewalls and load balancers. Therefore implementers and
   operators need to be aware that on many paths through the Internet,
   IPv6 fragmentation will fail. Legacy applications and transport layer
   protocols that do not conform to the previous paragraph can expect
   connectivity failures as a result.

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Jun 2013 10:43:04 +0900

> In reality, you can not count on the Internet working.  Despite that,
> it mostly works, most everywhere you need it to work, most of the
> time.  Only occasionally, does one encounter failure.

unlike pmtud

> One of these days, I'll understand why operators don't make it
> MANDATORY

good luck with that

randy

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 27 Jun 2013 04:14:43 +0000

> of the potentially-lng convergence time (i.e. time to discover the PMTU).

And when ICMP is blocked, and the convergence interval is infinite...?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Jun 2013 06:52:05 +0200

> And when ICMP is blocked, and the convergence interval is infinite...?

Not sure what you mean.

There ae two ways to implement RFC4821:

1) As a complete replacement of ICMP-based PMTUD, or,
2) For PMTUD back-whole detection

Implementers I've talked to are fine with 2, but not with 1.

If you process ICMPs, then when ICMP errors are received you don't need
to rely on timeouts.

Thanks,

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 27 Jun 2013 07:52:41 +0200

>something like the following:

Nearly, skip five words: "and the IPv6 fragment header". One more time: a
client of mine deploy sensor network applications using fragmentation. Not
just for fun, no because of 2460. Think about this: if this ID becomes an RFC
(or even earlier) someone posts a patch removing fragmentation from
Linux/*BSD,3 month later all distribution ship a fragmentation/reassembly less
stack. This breaks application, application which cannot changed because they
are hard wired into silicon (DSP). This incompatible protocol break needs more
time to mature out everywhere.

I support the deprecation of fragmentation, but we need reassembling for a
transition period - not fragmentation. But this is not in contradiction with
the current effort here - everybody can be happy. My recommendation (slightly
changed version, see second sentence):

3.  Recommendation

	 This memo deprecates IPv6 fragmentation. Host SHOULD still be able to
	 reassembly fragmented packets.  Application and transport layer protocols
	 SHOULD support effective PMTU discovery [RFC4821], since ICMP-based PMTU
	 discovery [RFC1981] is unreliable. Any application or transport layer
	 protocol that cannot support effective PMTU discovery MUST NOT in any
	 circumstances send IPv6 packets that exceed the IPv6 minimum MTU of 1280
	 bytes.

Hagen

---

From: Marc Lampo <[email-masked]>
Date: Thu, 27 Jun 2013 08:39:24 +0200

> This incompatible protocol break ...

Incompatible protocol or is it time for the next IP version, without
fragmentation right from the beginning ?

As the reasons, stated in the draft, also apply to IPv4.  Would we think
about deprecating the use of fragmentation fields in the IPv4 header and
recommending they MUST always be set to 0 ?

Kind regards,

Marc Lampo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 27 Jun 2013 15:33:15 +0000

Hi Brian,

> Brian E Carpenter
> Sent: Wednesday, June 26, 2013 6:14 PM
> To: 6man
> Subject: draft-bonica-6man-frag-deprecate
> 

But, if those 1280 packets go into a tunnel they become (1280 + HLEN)
and are vulnerable to loss. This is even before we start talking about
tunnels-within-tunnels. It should therefore be well established by now
that tunnels over IPv6 MUST be capable of some form of frag/reass.

>    connectivity failures as a result.

Without some form of frag/reass, tunnels over IPv6 will black-hole.
If IPv6 frag/reass is off the table, then we simply need something
else. That something else is SEAL.

Thanks - Fred

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 27 Jun 2013 21:32:59 +0300

Hi,

there are certainly many security issues in IPv6 related with
fragmentation, but still not convinced if its use should be deprecated
completely. We should not remove any feature that may cause security
issues. We may need it some day. On the contrary, I believe that we should
try to fix it.

I believe that some of the draft RFCs proposed by Fernando Gont are in the
good direction (regarding the RA-Guard case, the generation of the fragment
id values, etc), as well as the newly accepted RFC regarding the handling
of atomic fragments.   Apart from the above, what remains to be fixed, in
my humble opinion, are the following:

a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unless
they are atomic fragments or the last fragment of a datagram).
b. RFC 5722 should be updated so as only the overlapping fragments to be
dropped, not all the ones already received, or the ones that follow (as it
is the recommendation now). This is already implemented by FreeBSD and
seems to me the most proper way for handling overlapping fragments.

We should also never forget that the rest of IPvt6Extension headers can
result in datagrams much bigger than 1280 bytes, 1500 bytes, or even more.
So, if you want to deprecate fragmentation in IPv6, you should also
deprecate or at least change the extension headers usage in IPv6. Which
actually means, redesign IPv6.

Just my 0.02$

Antonios

2013/6/27 Brian E Carpenter <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 27 Jun 2013 18:56:08 +0000

Hi,

> a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unless they are atomic fragments or > the last fragment of a datagram).

I disagree that all fragments less than 1280 bytes should be classified
as "tiny fragments". For nested tunnels, for example, the first tunnel
ingress may wish to fragment to a smaller size (e.g. 1024 bytes) so that
subsequent tunnel ingresses do not have to fragment further. I think a
"tiny fragment" is simply an initial fragment that does not include all
extension headers plus upper layer headers.

On the other hand, SEAL fragments cannot be smaller than 256bytes
so there is no possible way to create a truly tiny SEAL first fragment.
SEAL also requires the sender to include all upper layer headers in
the first fragment unless they absolutely cannot fit due to a size
restriction.

> b. RFC 5722 should be updated so as only the overlapping fragments to be dropped, not all the ones
> already received, or the ones that follow (as it is the recommendation now). This is already
> implemented by FreeBSD and seems to me the most proper way for handling overlapping fragments.

SEAL has a strategy for dealing with overlapping fragments. It would
be interesting to hear whether it meets your understanding of how best
to handle overlaps because we can still make changes now if something
doesn't look right.

> We should also never forget that the rest of IPvt6Extension headers can result in datagrams much
> bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to deprecate fragmentation in IPv6,
> you should also deprecate or at least change the extension headers usage in IPv6. Which actually means,
> redesign IPv6.

I agree that excessively-long extension headers are problematic
in any case - especially if the length of the extension headers
exceeds the effective path MTU. That needs to be fixed no matter
what frag/reass scheme is applied.

Thanks - Fred

Antonios

3.  Recommendation

---

From: Antonios Atlasis <[email-masked]>
Date: Thu, 27 Jun 2013 23:15:44 +0300

Hi Fred,

2013/6/27 Templin, Fred L <[email-masked]>

> Hi,
>
> > a. Tiny fragments (smaller than 1280 bytes) should not be accepted
> (unless they are atomic fragments or > the last fragment of a datagram).
>

Actually, I was not talking only about SEAL, but generally. If this is the
case, the minimum acceptable size of fragments could be discussed/adjusted
accordingly, but as it is, OS accept as small as 56 bytes fragments!

> dropped, not all the ones

Again, generally speaking (and not just for SEAL) RFC 5722 "allows" the
abuse of its recommended policy for launching DoS attacks (a single
overlapping fragment will result in discarding a whole datagram). On the
contrary, if  only the overlapping fragment is discarded, at least DoS will
be slightly more difficult.

> result in datagrams much
I agree

Thank you too

Antonios

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jun 2013 15:24:26 -0700

Antonios Atlasis wrote:
...
> Again, generally speaking (and not just for SEAL) RFC 5722 "allows"
> the abuse of its recommended policy for launching DoS attacks (a 
> single overlapping fragment will result in discarding a whole 
> datagram). On the contrary, if  only the overlapping fragment is 
> discarded, at least DoS will be slightly more difficult.  
 
DoS is more difficult, but packet hijack is easier. All an attacker needs to
do is inject a set of fragments before the next one from the source to cause
it to appear to be an overlap and rejected. Once the attacker can get the
real fragments rejected as overlaps, the rest of the packet is filled with
bogus attack fragments. Wouldn't it have been better to drop the whole
datagram? DoS is a problem, but undetected malicious data is worse.

Tony

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 27 Jun 2013 22:48:25 +0000

On Jun 26, 2013, at 11:39 PM, Marc Lampo <[email-masked]<mailto:[email-masked]>> wrote:

Would we think about deprecating the use of fragmentation fields in the IPv4 header and recommending they MUST always be set to 0 ?

I would say "no", for the same reasons that I think it's a poor idea in IPv6. It pushes the requirement to match MTU to the client of IP. Some clients, notably IPv4, have ways to do that. Some have been noted that don't.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jun 2013 09:31:30 +1000

In message <[email-masked]>, "Tony Hain" writes:
> DoS is more difficult, but packet hijack is easier. All an attacker needs
> to do is inject a set of fragments before the next one from the source to
> cause it to appear to be an overlap and rejected. Once the attacker can get
> the real fragments rejected as overlaps, the rest of the packet is filled
> with bogus attack fragments. Wouldn't it have been better to drop the whole

Then add a cryptographic checksum of the original packet when fragmenting.
48 bits in a HBH should be enough.

---

From: Karl Auer <[email-masked]>
Date: Fri, 28 Jun 2013 10:00:11 +1000

> 48 bits in a HBH should be enough.

Why HBH? Is that to prevent it being send in a fragment itself? And, um,
I hate to suggest this, but isn't that sort of exactly what the AH
header is for? I know, I know.... (covers head, ducks)

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 00:09:07 +0000

> Karl Auer
> Sent: Thursday, June 27, 2013 5:00 PM
> To: [email-masked]
> Subject: Re: draft-bonica-6man-frag-deprecate
> 

SEAL has the *option* to insert a per-segment HMAC that the destination
can use for data origin verification. Sort of like AH, but this is only
one *optional* mode of operation.

But that said, going back to Tony's scenario why would an adversary
that is already able to get the destination to accept its packets
bother with finessing the reassembly cache? Upper-layer checksums
would weed out bad reassemblies, while the attacker could much
more easily just inject whole packets that are evil.

Thanks - Fred

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jun 2013 10:15:27 +1000

> header is for? I know, I know.... (covers head, ducks)

I really don't care which header it is included in.  If we could
drop it to 32 bits we could just set the fragment id to the checksum
and use one of the reserved bits to indicate that one should treat
it as a checksum.  My gut feel is that 32 bits is a little to small
however.

---

From: Erik Nygren <[email-masked]>
Date: Fri, 28 Jun 2013 11:36:18 -0400

If we accept that 1280 is the only non-broken MTU for IPv6, I share
James' fear that this would spell doom for IPv6 on the broad Internet
and land us in a world where broad IPv6 adoption stalls out and IPv4
ith CGN dominates.  The current reality is that many hosts do have
1500 byte MTUs (as Tore observed with many of the top Alexa sites, and
presumably also with the default configuration for many hosts out
there).  We need to make sure that this current reality keeps working.

If content providers need to drop their IPv6 MTU/MSS down below that
of IPv4 (eg, to 1280), this has the potential to be enough of a
performance difference (even a few percent matters!) to cause many
content providers to hold off indefinitely on dual-stacking.  If large
ISPs or enterprises need to find some way to get their end users down
to lower MTUs or need to wait for some OS updates to do some other
form of PMTU discovery, then IPv6 is DOA for them as well and they'll
have a good excuse to not roll out out.

As such, I agree with other comments that it's important
to re-emphasize that any environment that both blocks ICMPv6 PTB
and at the same time doesn't allow 1500 byte packets through is broken
and needs to get fixed.  This also means that anyone deploying
or implementing a tunnel (or VPN) needs to carefully consider
how they'll deal with this.

For fragments themselves, would it make more sense to constrain
their usage rather than deprecate them entirely?  For example,
express that certain headers may not appear in fragments,
and also perhaps express that overlapping fragments or overly
spase fragments are likely to be dropped?

In looking at a global end-user facing HTTP (TCP) environment,
I'm seeing around 0.0005% of the packets arrive as fragments
which sounds similar to some of the other numbers on this thread.

     Erik

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 16:00:33 +0000

Hi,

> Erik Nygren
> Sent: Friday, June 28, 2013 8:36 AM
> To: Brian E Carpenter
> Cc: 6man
> ith CGN dominates.

It doesn't have to be that way. With SEAL, packets up to 1500
get through no matter what, and larger packets also get through
if the path MTU is sufficiently large.

> The current reality is that many hosts do have

Right. Tunnels over IPv6 absolutely require some form of
frag/reass to meet the IPv6 minMTU of 1280. SEAL goes it one
better and ensures that everything up to 1500 makes it through. 

> spase fragments are likely to be dropped?

I think the question has been raised as to whether standard IPv6
frag/reass can be re-worked now that it is already in widespread
deployment. SEAL fixes these and other issues and also has the
advantage that it doesn't yet have a widespread deployed base.

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Fri, 28 Jun 2013 12:21:56 -0700

And this is where I point at RFC 2473 "Generic Packet Tunneling in IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote for handy reference below:

>> 7.2 IPv4 Tunnel Packet Fragmentation
>> 
>>    When an IPv4 original packet enters a tunnel, if the original packet
>>    size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
>>    entry-point and the tunnel exit-point, minus the size of the tunnel
>>    header(s)), it is handled as follows:
>> 
>>         (a)  if in the original IPv4 packet header the Don't Fragment  -
>>              DF - bit flag is SET, the entry-point node discards the
>>              packet and returns an ICMP message.  The ICMP message has
>>              the type = "unreachable", the code = "packet too big", and
>>              the recommended MTU size field set to the size of the
>>              tunnel MTU - see sections 6.7 and 8.3.
>> 
>>         (b)  if in the original packet header the Don't Fragment - DF  -
>>              bit flag is CLEAR, the tunnel entry-point node encapsulates
>>              the original packet, and subsequently fragments the
>>              resulting IPv6 tunnel packet into IPv6 fragments that do
>>              not exceed the Path MTU to the tunnel exit-point.

This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation and Reassembly" which I will also quote for handy reference:

>> 5.3.  Fragmentation and Reassembly
>> 
>>    Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
>>    traffic over IPv6 will reduce the effective MTU of the datagram.
>>    Unfortunately, path MTU discovery [RFC1191] is not a reliable method
>>    to deal with this problem.
>> 
>>    A solution to deal with this problem is for the service provider to
>>    increase the MTU size of all the links between the B4 element and the
>>    AFTR elements by at least 40 bytes to accommodate both the IPv6
>>    encapsulation header and the IPv4 datagram without fragmenting the
>>    IPv6 packet.
>> 
>>    However, as not all service providers will be able to increase their
>>    link MTU, the B4 element MUST perform fragmentation and reassembly if
>>    the outgoing link MTU cannot accommodate the extra IPv6 header.  The
>>    original IPv4 packet is not oversized.  The packet is oversized after
>>    the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
>>    fragmented.  Fragmentation MUST happen after the encapsulation of the
>>    IPv6 packet.  Reassembly MUST happen before the decapsulation of the
>>    IPv4 packet.  A detailed procedure has been specified in [RFC2473]
>>    Section 7.2.

Clearly, this proposal to deprecate IPv6 fragmentation headers entails an update to RFC 2473 and RFC 6333 as well as RFC 2460.  The procedure for encapsulating IPv4 packets with DF=0 in IPv6 tunnels where the path MTU is less than typical IPv4 path MTU currently requires tunnel endpoints to use IPv6 fragment headers. I guess they have to stop doing that if this RFC is published.

I'm also excited to learn about how we're going to add PLPMTUD to GRE and tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280 octets.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 19:32:28 +0000

Hi James,

> james woodyatt
> Sent: Friday, June 28, 2013 12:22 PM
> To: 6man
> And this is where I point at RFC 2473 "Generic Packet Tunneling in
> IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote
> for handy reference below:

Yes, that has already been pointed out on the intarea list where some
parallel discussions have transpired.

> This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation
> and Reassembly" which I will also quote for handy reference:
> 
> Clearly, this proposal to deprecate IPv6 fragmentation headers entails
> an update to RFC 2473 and RFC 6333 as well as RFC 2460.  The procedure
> for encapsulating IPv4 packets with DF=0 in IPv6 tunnels where the path
> MTU is less than typical IPv4 path MTU currently requires tunnel
> endpoints to use IPv6 fragment headers. I guess they have to stop doing
> that if this RFC is published.

Right; it is already well established that tunnels over IPv6 MUST
perform some form of frag/reass in order to meet the IPv6 minMTU.
 
> I'm also excited to learn about how we're going to add PLPMTUD to GRE
> and tunnel-mode IPsec ESP so they have some hope of using path MTU
> larger than 1280 octets.

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Fri, 28 Jun 2013 13:41:03 -0700

On Jun 28, 2013, at 12:32 , Templin, Fred L <[email-masked]> wrote:
> [I wrote:]

I'm not sure I read this comment correctly.  Are you suggesting that we should replace tunnel-mode ESP and GRE tunnels with SEAL in order to get PLPMTUD to work?  Are we all *really* okay with just trashing ESP and GRE like that?  Maybe we should be moving to deprecate those too?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 20:54:03 +0000

Hi James,

> Sent: Friday, June 28, 2013 1:41 PM
> To: 6man
> I'm not sure I read this comment correctly.  Are you suggesting that we
> should replace tunnel-mode ESP and GRE tunnels with SEAL in order to
> get PLPMTUD to work?

No, I am saying that these and others are compatible with SEAL.
The SEAL header has a "next header" field exactly like an IPv6
extension header, and that next header could be IPsec, GRE, etc.
Used in this way, the SEAL header has the same footprint as an
IPv6 fragmentation header.

That said, SEAL could be used in place of other tunnel types like
GRE and IPv6/IPv6. How they all fit together is something we should
discuss either here or in intarea.

> Are we all *really* okay with just trashing ESP
> and GRE like that?  Maybe we should be moving to deprecate those too?

Not what I am suggesting. SEAL+GRE, SEAL+IPsec-ESP, etc. all work
just fine.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jun 2013 08:57:35 +1200

One comment below...

> Clearly, this proposal to deprecate IPv6 fragmentation headers entails an update to RFC 2473 and RFC 6333 as well as RFC 2460.  The procedure for encapsulating IPv4 packets with DF=0 in IPv6 tunnel…

All this is why it seems reasonable to deprecate ("SHOULD NOT") fragmentation
by hosts without disabling reassembly, and leave a window for cases such as
foo-in-IPv6 tunnels where fragmentation is still useful. You just have to
know that those tunnels won't work across certain middleboxes.

> I'm also excited to learn about how we're going to add PLPMTUD to GRE and tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280 octets.

You mean a better chance than they have today, except on carefully tailored
paths?

Let's face it, this train left the station a while back. (This doesn't
mean I'm happy, but it is what it is.)

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 21:03:21 +0000

Hi Brian,

> mean I'm happy, but it is what it is.)

Do you mean that you want to give up and declare that the fixed
MTU for IPv6 is 1280 now and for always (and remember, that still
would not excuse tunnels from using frag/reass)?

I still think the situation can be salvaged with something like SEAL,
but if we want to just give up then I think I agree with others that
we may need to increment the IP protocol version (I for one would not
like to see that).

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Fri, 28 Jun 2013 17:51:36 -0400

> that tunnels over IPv6 MUST be capable of some form of frag/reass.

in my understanding the 1280 minimum MTU for IPv6 was already chosen to accommodate nested tunnels.
the expectation made, I believe, was that native links support at least an MTU of 1500 bytes,
allowing 220 bytes for tunnel encap (5 IPv6 headers).

you want to avoid reassembly at tunnel endpoints, if you care about performance that is.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Jun 2013 23:53:41 +0200

Folks,

I wanted to comment on some met-issues regarding the deprecation of the
IPv6 fragmentation function.

** On the motivation of deprecating the fragmentation function **

So far (and without having read Ron's recent I-D -- shame on me), it
looks like the main two reasons for deprecating the fragmentation
function are:

1) The inability of middle-boxes to parse past the first XXX bytes of a
packet

2) Unavailability of the connection-id (five-tuple) in the non-first
fragments.

Regarding "1)", I believe that deprecating fragmentation is not really
the right solution. If anything, one could require the entire header
chain to be within the first XXX bytes of a packet (as a former version
of draft-ietf-6man-oversized-header-chain did). Besides, if we're going
to deprecate the fragmentation function because of this, then we should
also deprecate all extension headers, because they might lead to the
same issue.

Regarding "2)", IPv4 doesn't have the connection-id in the non-first
fragments, either. So whatever middle-boxes are doing, they should/could
do it in the same way as they currently do for IPv4.

** On the impact on applications **

It has been stated that fragmentation is uncommon. However, multiple
uses for IPv6 fragmentation have been mentioned -- from NFS, to tunnels
or the recent data posted by Mark Andrews. I think such use cases should
really be considered.

That aside, if the IPv6 fragmentation function is removed, it also means
that UDP can only be used for applications that send datagrams
smaller than 1280 bytes (assuming no Path-MTUD for UDP). I haven't done
a survey myself, but I wonder to what extent one can really conclude
there's no need for that (e.g., I'm told that in the stock market sector
they employ multicast... which might mean that they need to send such
"large" UDP datagrams).

** Therefore.... **

Considering the above, I guess I'm in the camp of "avoid fragmentation
where possible". However, I don't think I'd go as far as deprecating it.

Just my two cents.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jun 2013 10:26:24 +1200

> would not excuse tunnels from using frag/reass)?

No. I believe that (a) strongly recommending packetizatiion layer
PMTUD and deprecating fragmentation at source is a sound long
term policy and (b) accepting that strapping the MTU at 1280 is
a reasonable short term policy. If (a) progressively pervades
the installed base then (b) can be dropped as the years go by.

(Though frankly I have never seen MTU problems in v6 since I stopped
trying to use 6to4; I've used three different configured tunnel
solutions, and various native services, without problems. So while
there are clearly paths with this problem, I suspect they're a minority
even today.)

> we may need to increment the IP protocol version (I for one would not

In effect using SEAL is part of (a), for the cases where tunels
are used, isn't it?

Talk of changing the version number doesn't have much to do with
the world that I live in. We have plenty of experience now of
how easy it isn't to change the version number.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 22:27:21 +0000

Hi Ole,

> accommodate nested tunnels.

Right, but..

> the expectation made, I believe, was that native links support at least

But, that expectation went out the window at the same time the IPv6
minMTU was set to 1280 - so now 1280 is all that can be expected.

So, without fragmentation, when the tunnel ingress receives a 1280
packet, it emits a (1280+HLEN) packet. If that packet is dropped
at a link that configures a 1280 MTU, then it simply black holes.

> allowing 220 bytes for tunnel encap (5 IPv6 headers).

Tunnels within tunnels presents an additional pain point, but the
plain truth is that IPv6 links only need to configure a 1280 MTU;
not a 1500.

> you want to avoid reassembly at tunnel endpoints, if you care about

Unfortunately, reassembly is absolutely necessary if the tunnel is
configured over a path that contains at least one 1280 link (see above).

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 22:33:12 +0000

Hi Fernando,

> where possible". However, I don't think I'd go as far as deprecating

I was originally thinking this way too, but now I am thinking
that deprecation of an old method is often the first step in
the path to adoption of a new method that avoids the old issues.
There have been examples in the past (e.g., deprecation of site
locals leading to ULAs), and I don't see why it would be any
different in this case.

Thanks - Fred
fred.l.templin@boeing,cim

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jun 2013 22:44:32 +0000

Hi Brian,

> Sent: Friday, June 28, 2013 3:26 PM
> To: Templin, Fred L
> Cc: james woodyatt; 6man
> term policy

No disagreement here.

> and (b) accepting that strapping the MTU at 1280 is

Once a link sets a 1280 MTU, how will it know that it is now
safe to increase the MTU? And, once set, how can we expect
operators to go back and re-set in the future. IMHO, strapping
the MTU to 1280 everywhere now would become ossified long into
the future.

> In effect using SEAL is part of (a), for the cases where tunels

I was originally thinking about SEAL for just tunnels, but the
realization I am coming to is that it can also be used anywhere
the IPv6 fragmentation header can be used - i.e., both tunnel
and transport modes are possible. That includes use with "atomic
fragments" and assurance that the ULP headers are contained in
the first fragment. Think of deprecation of the IPv6 fragment
header as giving way to a new method that fixes fragmentation,
i.e., the same as deprecation of site local gave way to ULA.

> how easy it isn't to change the version number.

It was a poor pun on my part, and not something I would advocate.
I do not mean to offend all of the contributors who have worked
long and hard to move IPv6 forward.

Thanks - Fred

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Sat, 29 Jun 2013 01:53:29 +0200

> locals leading to ULAs), and I don't see why it would be any

While browsing the draft I wondered if applications do handle the
EPROTO errno case for writes on a socket with a recevied icmp error
parameter-problem correctly today.

I doubt that recommending not implementing reassembly would be beneficial.

Greetings,

  Hannes

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jun 2013 16:20:09 +1200

On one point...

On 29/06/2013 10:44, Templin, Fred L wrote:
...
> the MTU to 1280 everywhere now would become ossified long into

It would certainly take years, but I think the end result would be
implementors raising the default to the real link MTU, one stack
at a time. I don't think you find many IPv4 stacks today with
the MTU set low by default.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Fri, 28 Jun 2013 22:35:01 -0700

> the MTU set low by default.

I think an argument can be made that in today's world 1500 MTU (which is 
the fairly ubiquitous default) IS actually low.

Doug

---

From: Antonios Atlasis <[email-masked]>
Date: Sat, 29 Jun 2013 09:54:55 +0300

+1 for Fernando's comments

2013/6/29 Fernando Gont <[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Sat, 29 Jun 2013 02:55:36 -0400

Fred,

> minMTU was set to 1280 - so now 1280 is all that can be expected.

quite the opposite.
physical link MTUs aren't getting smaller.
do you have any evidence that operators set the IPv6 MTU to a value smaller than the MTU supported
by the link-layer?

as far as I can see the setting IPv6 minimum MTU to 1280, which gives ample room for
nested tunnels works as designed.

> plain truth is that IPv6 links only need to configure a 1280 MTU;

again, why would anyone do that?
the pain here is fragmentation, not supporting an MTU larger than 1280.

> configured over a path that contains at least one 1280 link (see above).

reassembly in the network is a non-starter.
the vendor I'm most familiar with does not do this in hardware. sure, you can get reassembly, but at an order of one or two magnitudes less. if anyone know of platforms doing IPv6 fragment reassembly at line rate for 10G or 100G interfaces I'll stand corrected. ;-)
for now reassembly in the network is not realistic.

cheers,
Ole

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 30 Jun 2013 13:42:02 -0700 (PDT)

On Fri, 28 Jun 2013, Fernando Gont wrote:
Fernando> I wanted to comment on some met-issues regarding the deprecation of the
Fernando> IPv6 fragmentation function.
Fernando> 
Fernando> ** On the motivation of deprecating the fragmentation function **
Fernando> 
Fernando> So far (and without having read Ron's recent I-D -- shame on me), it
Fernando> looks like the main two reasons for deprecating the fragmentation
Fernando> function are:
Fernando> 
Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a
Fernando> packet
Fernando> 
Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first
Fernando> fragments.

I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013:

Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment.

The flow label, if properly set at or near the source, could plausibly address "2)" -- see 
https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/?include_text=1

However, it won't help middle boxes that implement stateless packet filters.  Indeed, such 
boxes have fundamental problems with non-first fragments irrespective of how many bytes of 
extension headers they can parse or whether there are sufficient length limits on the extension 
header chain that guarantee that the L4 header always appears in the first fragment.

As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether 
middle boxes that implement stateless packet filters with a "default-deny" policy will be a 
significant part of the landscape indefinitely, regardless of what the IETF says about their 
merits or lack thereof.  If so, fragmented IP datagrams will continue be problematic in the general 
case; and since the job of this (or any other) IETF WG is to make the internet work better, it will 
be incumbent on the WG to deal with the issue.  Ron Bonica and co-authors have made one proposal to 
do just that.

Thinking aloud ...

If we decide that the only path forward is to deprecate IPv6 fragmentation and reassambly (presumably 
not IPv4, since it's at end of life), the next question I see is what can or should be done to allow 
UDP and kin to send large datagrams.  A UDP replacement with fragmentation and reassembly built in to 
the transport layer is one possibility.  The questions that come to mind are (a) is this capability 
actually needed, and if so, (b) can it be incrementally deployed, in the face of middle boxes with 
"default deny" policies causing them to discard protocols that they don't know?

//cmh