Folks,
I have just received private communication from someone associated with
http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf.
He informs me that I may have misinterpreted the paper's results.
Specifically, packets fragmented to 1280 bytes were filtered on only
Hi,
I would like to make one minor edit to what I have been saying:
> The Internet will then
> naturally gravitate toward larger packets, and eventually the
> Internet "cell size" will bump up from 1500 to 8KB.
I am not looking for a fixed "Internet cell size", and the 8KB
I mentioned was intend
Hi Brian,
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Friday, June 28, 2013 9:20 PM
> To: Templin, Fred L
> Cc: james woodyatt; 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.
With all this talk of 1280 as the minimum *link* MTU, I think it's easy
to forget that 2460 states:
> A node must be able to accept a fragmented packet that, after
> reassembly, is as large as 1500 octets. A node is permitted to
> accept fragmented packets that reassemble to more than 1500 o
On 06/28/2013 09:20 PM, Brian E Carpenter wrote:
On one point...
On 29/06/2013 10:44, Templin, Fred L wrote:
...
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.
On
On one point...
On 29/06/2013 10:44, Templin, Fred L wrote:
...
>> 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.
>
> Once a link sets a 1280 MTU, how will it k
Hi Brian,
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Friday, June 28, 2013 3:26 PM
> To: Templin, Fred L
> Cc: james woodyatt; 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
On 29/06/2013 09:03, Templin, Fred L wrote:
> Hi Brian,
>
>> 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.)
>
> 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
Hi Brian,
> 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.)
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/re
One comment below...
On 29/06/2013 07:21, james woodyatt wrote:
> On Jun 28, 2013, at 08:36 , Erik Nygren wrote:
>> [...]
>> 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
Hi James,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> james woodyatt
> Sent: Friday, June 28, 2013 1:41 PM
> To: 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
>
On Jun 28, 2013, at 12:32 , Templin, Fred L wrote:
> [I wrote:]
>>
>> 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
Hi James,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> james woodyatt
> Sent: Friday, June 28, 2013 12:22 PM
> To: 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
>
On Jun 28, 2013, at 08:36 , Erik Nygren wrote:
> [...]
> 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 t
Hi,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Erik Nygren
> Sent: Friday, June 28, 2013 8:36 AM
> To: Brian E Carpenter
> Cc: 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> dep
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 o
On 06/27/2013 06:14 AM, Fred Baker (fred) wrote:
>
> On Jun 26, 2013, at 4:52 PM, Fernando Gont
> wrote:
>
>> 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
On Jun 26, 2013, at 4:52 PM, Fernando Gont
wrote:
> 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, s
>> 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.
unlike pmtud
> One of these days, I'll understan
In message <3ae1b933-97b8-4312-8829-bc02ab666...@apple.com>, james woodyatt
writes:
> On Jun 25, 2013, at 20:30 , Fred Baker (fred) wrote:
> > On Jun 25, 2013, at 12:42 PM, Randy Bush wrote:
> >>
> >> in reality, you can not count on pmtud working
>
> In reality, you can not count on the Inte
On Jun 25, 2013, at 20:30 , Fred Baker (fred) wrote:
> On Jun 25, 2013, at 12:42 PM, Randy Bush wrote:
>>
>> 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 ti
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 obs
In message <20130626202205.GA6135@virgo.local>, Hagen Paul Pfeifer writes:
> * Mark Andrews | 2013-06-26 10:06:45 [+1000]:
>
> >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).
>
> problem repor
* Mark Andrews | 2013-06-26 10:06:45 [+1000]:
>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).
problem report number or link into GNATS database?
Hi,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Usman Latif
> Sent: Tuesday, June 25, 2013 6:07 PM
> To: ipv6@ietf.org
> Subject: RE: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith wrote:
> - Original Message -
>> From: Fred Baker (fred)
>> To: Randy Bush
>> Cc: IPv6 Deployment Prevention
>> Sent: Wednesday, 26 June 2013 1:30 PM
>> Subject: Re: New Version Notification for
>>
- Original Message -
> From: Fred Baker (fred)
> To: Randy Bush
> Cc: IPv6 Deployment Prevention
> Sent: Wednesday, 26 June 2013 1:30 PM
> Subject: Re: New Version Notification for
draft-bonica-6man-frag-deprecate-00.txt
>
>
> On Jun 25,
>> 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.
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
On Jun 25, 2013, at 12:42 PM, Randy Bush 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.
IETF IPv6 working group mailing li
>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 consum
send a message with subject or body 'help' to
> >ipv6-requ...@ietf.org
> >
> > You can reach the person managing the list at
> > ipv6-ow...@ietf.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Co
In message <014201ce7208$1378c5f0$3a6a51d0$@tndh.net>, "Tony Hain" writes:
> 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
digest..."
>
>
> Today's Topics:
>
> 1. RE: New Version Notification for
> draft-bonica-6man-frag-deprecate-00.txt (Ronald Bonica)
> 2. Re: New Version Notification for
> draft-bonica-6man-frag-deprecate-00.txt (Fred Baker (fred))
> 3. Re:
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 sinc
On Tue, 25 Jun 2013 16:36:51 +
Christian Huitema wrote:
> > 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
In message <51ca2e75.7050...@gmail.com>, Brian E Carpenter writes:
> On 26/06/2013 11:23, Randy Bush wrote:
> ...
>
> > 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
On 26/06/2013 11:23, Randy Bush wrote:
...
> 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.
The only times I've seen hard FAILs with apparently operational
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
r
On 26/06/2013 11:08, james woodyatt wrote:
> On Jun 25, 2013, at 13:13 , Randy Bush wrote:
>> ron has made one suggestion. though brutal, its simplicity and its
>> recognition of reality appeal to me.
>
> Why not go large and deprecate all of RFC 2460?
>
> I'm not entirely joking. If the pract
In message <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net>, "Tony Hain" writes:
> Tore Anderson wrote:
> > * George Michaelson
> >
> > > One thing I *strongly* agree with: the sentence at 2.2:
> > >
> > > The effective MTU for IPv6 is 1280 bytes.
> > >
> > > This is looking compellin
> 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 poin
On Jun 25, 2013, at 13:13 , Randy Bush wrote:
>
> ron has made one suggestion. though brutal, its simplicity and its
> 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 pra
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
Tore Anderson wrote:
> * George Michaelson
>
> > 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 believe this is a gross exaggeration. I'm running 1500 byt
> 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?
Randy,
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."
>>> s/might/do/
>> would you be able to answer why and where?
>
> perceived, rightly or wrongly, as an attack vector. they do
>>> 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."
>> s/might/do/
> would you be able to answer why and where?
perceived, rightly or wrongly, as an attack vector. they do similarly
for v4.
On Tue, Jun 25, 2013 at 12:27 PM, Templin, Fred L wrote:
> 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
Randy,
>> 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."
>
> s/might/do/
would you be able to answer why and where?
cheers,
Ole
On Jun 24, 2013, at 10:39 PM, Brian E Carpenter
wrote:
> On 25/06/2013 10:11, Ronald Bonica wrote:
>>> "New IPv6 host implementations MAY support IPv6 fragmentation and
>>> reassembly"
>>> break things. "New IPv6 host implementations MAY support IPv6
>>> fragmentation but MUST support reassembl
> 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 i
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 a
Brian E Carpenter wrote:
>
> 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."
+1
--
John Leslie
IETF IPv6 working group
* George Michaelson
> 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 believe this is a gross exaggeration. I'm running 1500 bytes MTU on
all the clients and servers
On 25/06/2013, at 8:17 PM, Glen Turner wrote:
> On Tue, 25 Jun 2013, Bob Hinden wrote:
>> 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
On Tue, 25 Jun 2013, Bob Hinden wrote:
> 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 t
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 be reworked as far as I
> can tell.
>
I think it would be good to fix this even if
In message , 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
In message , Randy Bush writes:
> > 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."
>
> s/might/do/
Which would be a totally mis-leading statement. "Some network operators
filter IPv6 fra
e?
>
> Ron
>
>
>> -Original Message-
>> From: Mark Andrews [mailto:ma...@isc.org]
>> Sent: Monday, June 24, 2013 9:53 PM
>> To: George Michaelson
>> Cc: Ronald Bonica; ipv6@ietf.org 6man-wg
>> Subject: Re: New V
On Jun 24, 2013, at 5:49 PM, Sheng Jiang 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 hav
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
In message <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.p
rod.outlook.com>, Ronald Bonica writes:
> 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?
I've
ailto:internet-dra...@ietf.org>
[mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>]
> Sent: Thursday, June 20, 2013 11:48 AM
> To: Ronald Bonica
> Subject: New Version Notification for
draft-bonica-6man-frag-deprecate-
> 00.txt
>
> 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."
s/might/do/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrati
On 25/06/2013 10:11, Ronald Bonica wrote:
>> "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 long
t: Monday, June 24, 2013 9:53 PM
> To: George Michaelson
> Cc: Ronald Bonica; ipv6@ietf.org 6man-wg
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
>
> In message rkq9...@mail.gmail.com>
> , George Michaelson writes:
>
On 6/24/13 5:04 PM, james woodyatt wrote:
On Jun 24, 2013, at 16:12 , joel jaeggli wrote:
On 6/24/13 3:35 PM, james woodyatt wrote:
On Jun 24, 2013, at 15:11 , Ronald Bonica wrote:
"Network operators MAY filter IPv6 fragments."
Ack. It is a statement of fact, not an IETF imposed requirement
In message
, George Michaelson writes:
> --===4023034923616370839==
> Content-Type: multipart/alternative; boundary=047d7b86e55011538004dff06308
>
> --047d7b86e55011538004dff06308
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica wrot
On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica wrote:
>** **
>
> 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
>> +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 , onl
On Jun 24, 2013, at 16:12 , joel jaeggli wrote:
> On 6/24/13 3:35 PM, james woodyatt wrote:
>> On Jun 24, 2013, at 15:11 , Ronald Bonica wrote:
"Network operators MAY filter IPv6 fragments."
>>> Ack. It is a statement of fact, not an IETF imposed requirement.
>> I hate to be *that* guy... bu
On 6/24/13 3:35 PM, james woodyatt wrote:
On Jun 24, 2013, at 15:11 , Ronald Bonica wrote:
"Network operators MAY filter IPv6 fragments."
Ack. It is a statement of fact, not an IETF imposed requirement.
I hate to be *that* guy... but, perhaps you want to bin this whole draft if you
don't wan
On Jun 24, 2013, at 15:11 , Ronald Bonica wrote:
>>
>> "Network operators MAY filter IPv6 fragments."
>
> Ack. It is a statement of fact, not an IETF imposed requirement.
I hate to be *that* guy... but, perhaps you want to bin this whole draft if you
don't want to impose that requirement.
>>
>
> "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 e
* Hagen Paul Pfeifer | 2013-06-24 22:40:09 [+0200]:
>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 cha
* Ronald Bonica | 2013-06-21 19:00:51 [+]:
>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
One of my clients using exten
o: Ronald Bonica
>Cc: "ipv6@ietf.org 6man-wg"
>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)
nts.
>
> Ron
>
>
> > -Original Message-
> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > Sent: Thursday, June 20, 2013 11:48 AM
> > To: Ronald Bonica
> > Subject: New Version Notification for draft-bonica
Hi Fred,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Fred Baker (fred)
> Sent: Sunday, June 23, 2013 4:12 PM
> To: Tore Anderson
> Cc: ipv6@ietf.org 6man-wg
> Subject: Re: New Version Notification for draft-bonica-6
>> 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
On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote:
> * Fred Baker (fred)
>
>> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote:
>>> - 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 orig
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
>
> +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
etf.org 6man-wg
> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
>
> * Ronald Bonica
>
> > [draft-bonica-6man-frag-deprecate]
>
> Being an operator I would definitively welcome getting rid of the
> complexities dealing with IPv6
* Fred Baker (fred)
> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote:
>> - 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.
>
> It *could* fragment the
In message <51c7a69f.40...@dougbarton.us>, Doug Barton writes:
> 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
n, Fred L
> Sent: Monday, June 24, 2013 7:02 AM
> To: Ronald Bonica
> Cc: ipv6@ietf.org 6man-wg
> Subject: RE: FW: New Version Notification for
> draft-bonica-6man-frag-deprecate-00.txt
>
> Hi,
>
> Deprecation of IPv6 fragmentation would make life difficult for IPv6
> tu
On 06/21/2013 01:52 PM, Brian E Carpenter wrote:
On 22/06/2013 07:53, Ronald Bonica wrote:
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, a
>From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>Fred Baker (fred)
>Sent: Saturday, June 22, 2013 3:49 AM
>To: Ronald Bonica
>Cc: ipv6@ietf.org 6man-wg
>Subject: Re: New Version Notification for
>draft-bonica-6man-frag-deprecate-00.txt
>
>I sup
In message <8c48b86a895913448548e6d15da7553b921...@xmb-rcd-x09.cisco.com>,
"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
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 rarel
On 24/06/2013, at 8:41 AM, Fred Baker (fred) wrote:
>
> 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
> o
On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote:
> - 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.
It *could* fragment the IPv4 packet and send it in tw
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
; > To: Ronald Bonica
> > Cc: Ray Hunter; ipv6@ietf.org 6man-wg
> > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-
> > deprecate-00.txt
> >
> > On 22/06/2013 07:53, Ronald Bonica wrote:
> > >> I don't 100% agree. I
* 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 protocol
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Friday, June 21, 2013 4:53 PM
> To: Ronald Bonica
> Cc: Ray Hunter; ipv6@ietf.org 6man-wg
> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-
> deprecate
On 22/06/2013 07:53, Ronald Bonica wrote:
>> 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-emptiv
> 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
1 - 100 of 112 matches
Mail list logo
