Templin, Fred L wrote:
Not necessarily, as IPv4 can take care of itself and IPv6
is hopeless.
IPv4 can take care of it how - with broken PMTUD or
As you know, RFC1191 style PMTUD is broken both for IPv4
and IPv6.
with broken fragmentation/reassembly?
Fragmentation is fine, especially
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 19, 2012 6:10 AM
To: Templin, Fred L
Cc: Owen DeLong; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
Not necessarily, as IPv4 can take care of itself
Templin, Fred L wrote:
If you wish, you can also consider Alternate 3 for 9kB:
72us@1Gbps, 7.2us@10Gbps, .72us@100Gbps, .072us@1Tbps.
So?
Have you learned enough about Moore's law that, at 10Gbps
era, 72us of delay is often significant?
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 12, 2012 4:47 AM
To: Templin, Fred L
Cc: Owen DeLong; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
If you wish, you can also consider Alternate 3
Templin, Fred L wrote:
Have you learned enough about Moore's law that, at 10Gbps
era, 72us of delay is often significant?
I frankly haven't thought about it any further.
That's your problem.
You say
1280+ belongs in ITU, and I say 1280- belongs in ATM.
As I already said, 9KB is fine for
As I already said, 9KB is fine for me.
Then you will agree that accommodation of MTU diversity
is a MUST (my point).
Fred
Templin, Fred L wrote:
As I already said, 9KB is fine for me.
Then you will agree that accommodation of MTU diversity
is a MUST (my point).
Not necessarily, as IPv4 can take care of itself and IPv6
is hopeless.
Masataka Ohta
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 12, 2012 2:12 PM
To: Templin, Fred L
Cc: Owen DeLong; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
As I already said, 9KB is fine for me
Here is Matt's full table and descriptive text:
Note that there is no specific reason to require any particular
MTU at any particular rate. As a general principle, we prefer
declining packet times (and declining worst case jitter) as you
go to higher rates.
Actual
On Tue, 05 Jun 2012 21:44:59 -0700, Owen DeLong said:
Second, you are correct. All L2 bridges for a given media type
should support the largest configurable MTU for that media
type, so, it is arguably a design flaw in the bridges. However,
in an environment where you have broken L2 devices
Owen DeLong wrote:
Given the combination of Moore's law and the deployment
lifecycle, designs we do today in this regard can be expected
to last ~12 years or more, so they should be prepared for
at least 16x. At 1,600 Gbps, that puts our target maximum
MTU up around 200M octets.
If
Owen DeLong wrote:
Really, no. The L3 MTU on an interface should be configured to the
lowest MTU reachable via that link without crossing a router. It's
just that simple. Anything else _IS_ a misconfiguration.
Perhaps this should be thought of as a limitation, rather then a feature.
Joe
A few more words on MTU. What we are after is accommodation
of MTU diversity - not any one specific size. Practical limit
is (2^32 - 1) for IPv6, but we expect smaller sizes for the
near term. Operators know how to configure MTUs appropriate
for their links. 1280 is too small, and turns the IPv6
Owen DeLong wrote:
Because bigger packets makes it rather circuit switching than
packet switching, which is the way to lose.
Er... No. It's attitudes like this that killed ATM.
ATM committed suicide because its slow target speed (64Kbps
voice) and inappropriate QoS theory required small cell
On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote:
On 2012-06-04 17:57, Owen DeLong wrote:
[..]
If you're going to redesign the header, I'd be much more interested
in having 32 bits for the destination ASN so that IDR can ignore IP
prefixes altogether.
One can already do that: route your
On Jun 4, 2012, at 7:47 PM, Jimmy Hess wrote:
On 6/4/12, Owen DeLong o...@delong.com wrote:
[snip]
Probing as you have proposed requires you to essentially do a binary search
to arrive
at some number n where 1280≤n≤9000, so, you end up doing something like
this:
[snip]
So, you waited for
Owen DeLong wrote:
But that's a whole lot more packets than working PMTU-D to get there and
you're also waiting for all those round trips, not just the 4 timeouts.
The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
100ms is 2.2 seconds. That's a long time to go without
A quick comment on probes. Making the tunnel ingress probe
is tempting but fraught with difficulties; believe me, I
have tried. So, having the tunnel ingress fragment when
necessary in conjunction with the original source probing
is the way forward, and we should advocate both approaches.
RFC4821
On 2012-06-04 23:06, Owen DeLong wrote:
On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote:
On 2012-06-04 17:57, Owen DeLong wrote: [..]
If you're going to redesign the header, I'd be much more
interested in having 32 bits for the destination ASN so that IDR
can ignore IP prefixes
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Monday, June 04, 2012 4:40 PM
To: Templin, Fred L; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
I'm not sure that a randomly-chosen skip value is even
necessary
In message e1829b60731d1740bb7a0626b4faf0a65d374a8...@xch-nw-01v.nw.nos.boeing
.com, Templin, Fred L writes:
A quick comment on probes. Making the tunnel ingress probe
is tempting but fraught with difficulties; believe me, I
have tried. So, having the tunnel ingress fragment when
necessary in
The proper solution is to have a field in IPv7 header to
measure PMTU. It can be a 8 bit field, if fragment granularity
is 256B.
We tried that for IPv4 and it didn't work very well [RFC1063].
You are welcome to try again in IPv7 when we have a green field.
Fred
fred.l.temp...@boeing.com
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Tuesday, June 05, 2012 7:55 AM
To: Templin, Fred L
Cc: Owen DeLong; Jimmy Hess; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
In message E1829B60731D1740BB7A0626B4FAF0A65D374A86CB@XCH-NW-
01V.nw.nos.boeing
Templin, Fred L wrote:
Have egresses with proper performance. That's the proper
operation.
How many core routers would be happy to reassemble at
line rates without a forklift upgrade and/or strong
administrative tuning?
You don't have to do it with core routers.
End systems are expected
Templin, Fred L wrote:
The proper solution is to have a field in IPv7 header to
measure PMTU. It can be a 8 bit field, if fragment granularity
is 256B.
We tried that for IPv4 and it didn't work very well [RFC1063].
IP option is a bad idea, which is partly why IPv6 sucks.
On 6/5/12, Owen DeLong o...@delong.com wrote:
[snip]
But that's a whole lot more packets than working PMTU-D to get there and
you're also waiting for all those round trips, not just the 4 timeouts.
The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
100ms is 2.2 seconds.
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 05, 2012 9:37 AM
To: Templin, Fred L
Cc: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
Have egresses with proper performance. That's the proper
Templin, Fred L wrote:
You don't have to do it with core routers.
Tunnel endpoints can be located either nearer the edges
or nearer the middle. Tunnel endpoints that are located
nearer the edges might be able to do reassembly at nominal
data rates, but there is no assurance of a maximum
On Jun 5, 2012, at 7:44 AM, Jeroen Massar wrote:
On 2012-06-04 23:06, Owen DeLong wrote:
On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote:
On 2012-06-04 17:57, Owen DeLong wrote: [..]
If you're going to redesign the header, I'd be much more
interested in having 32 bits for the
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 05, 2012 11:36 AM
To: Templin, Fred L; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
You don't have to do it with core routers.
Tunnel endpoints
On Jun 5, 2012, at 10:15 AM, Jimmy Hess wrote:
On 6/5/12, Owen DeLong o...@delong.com wrote:
[snip]
But that's a whole lot more packets than working PMTU-D to get there and
you're also waiting for all those round trips, not just the 4 timeouts.
The round trips add up if you're dealing with
Templin, Fred L wrote:
I am making a general statement that applies to all tunnels
everywhere.
General statement?
Even though you assume tunnel MTU 1500B and tunnel overhead 20B?
For those, specs say that all that is required
for MRU is 1500 and not 1500+20.
That is a requirement for
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 05, 2012 12:42 PM
To: Templin, Fred L
Cc: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
I am making a general statement that applies to all tunnels
On 2012-06-05 11:44, Owen DeLong wrote:
[..]
LISP et. al requires a rather complicated deployment and would be even
more complex to troubleshoot when it fails.
What I am proposing could, literally, be deployed with the existing system
still running as it does. The difference would be that
Templin, Fred L wrote:
General statement for IPv6-in-IPv4 tunneling, yes. But
inner fragmentation applies equally for *-in-* tunneling.
Even though you assume tunnel MTU 1500B
What I am after is a tunnel MTU of infinity. 1500 is
the minimum packet size that MUST get through. 1501+
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 05, 2012 2:44 PM
To: Templin, Fred L; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
General statement for IPv6-in-IPv4 tunneling, yes. But
inner
Templin, Fred L wrote:
Infinity? You can't carry 65516B in an IPv4 packet.
2) For tunnels over IPv6, let infinity equal (2^32 - 1)
You can't carry a 65516B IPv6 packet in an IPv4 packet.
Instead, see the last two lines in second last slide of:
On Jun 5, 2012, at 5:21 AM, Joe Maimon wrote:
Owen DeLong wrote:
But that's a whole lot more packets than working PMTU-D to get there and
you're also waiting for all those round trips, not just the 4 timeouts.
The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Tuesday, June 05, 2012 3:41 PM
To: Templin, Fred L
Cc: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
Infinity? You can't carry 65516B in an IPv4 packet.
2
On 6/5/12, Owen DeLong o...@delong.com wrote:
This is a horrible misconfiguration of the devices on that link.
If your MTU setting on your interface is larger than the smallest MTU
of any L2 forwarder on the link, then, you have badly misconfigured
Not really; The network layer and L2
Templin, Fred L wrote:
You can't carry a 65516B IPv6 packet in an IPv4 packet.
No, but you can carry a ((2^32 - 1) - X) IPv6 packet in
an IPv6 packet.
I'm afraid you wrote:
General statement for IPv6-in-IPv4 tunneling, yes. But
and
What I am after is a tunnel MTU of infinity.
in a
On Jun 5, 2012, at 6:02 PM, Jimmy Hess wrote:
On 6/5/12, Owen DeLong o...@delong.com wrote:
This is a horrible misconfiguration of the devices on that link.
If your MTU setting on your interface is larger than the smallest MTU
of any L2 forwarder on the link, then, you have badly
Bigger packets makes it rather circuit switching than packet
switching. The way to lose.
Faster is the way to go.
Why only fast when you can have both big *and* fast?
Because bigger packets makes it rather circuit switching than
packet switching, which is the way to lose.
Er... No.
On 6/3/12, Jeroen Massar jer...@unfix.org wrote:
If one is so stupid to just block ICMP then one should also accept that one
loses functionality.
ICMP tends to get blocked by firewalls by default; There are
legitimate reasons to block ICMP, esp w V6. Security device
manufacturers tend to
On 3 Jun 2012, at 22:41, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote:
Joe Maimon wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? ;)
Or was the fix incorporating the breakage into the basic design?
Yes.
On 3 Jun 2012, at 23:20, Jimmy Hess mysi...@gmail.com wrote:
On 6/3/12, Jeroen Massar jer...@unfix.org wrote:
If one is so stupid to just block ICMP then one should also accept that one
loses functionality.
ICMP tends to get blocked by firewalls by default
Which firewall product does that?
On Jun 3, 2012, at 11:20 PM, Jimmy Hess wrote:
On 6/3/12, Jeroen Massar jer...@unfix.org wrote:
If one is so stupid to just block ICMP then one should also accept that one
loses functionality.
ICMP tends to get blocked by firewalls by default; There are
legitimate reasons to block ICMP, esp
An L2 device should not be fragmenting L3 packets.
Layer 2 fragmentation used (20+ years ago) to be a common thing with bridged
topologies like token-ring to Ethernet source-routing. Obviously, no so much
anymore (at least I hope not), but it can and does happen.
I think part of the problem
Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? ;)
IPv4 without PMTUD, of course.
Because IPv6 requires ICMP packet too big generated against
multicast, it is designed to cause ICMP implosions, which
On 4 Jun 2012, at 06:36, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote:
Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? ;)
IPv4 without PMTUD, of course.
We are (afaik) discussing IPv6 in
On Jun 4, 2012, at 1:01 AM, Owen DeLong o...@delong.com wrote:
Any firewall/security device manufacturer that says it is will not get any
business from me (or anyone else who considers their requirements
properly before purchasing).
Unfortunately many technology people seem to have the idea,
On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote:
On 4 Jun 2012, at 06:36, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? ;)
IPv4
Hi,
There was quite a bit discussion on IPv6 PMTUD on the v6ops
list within the past couple of weeks. Studies have shown
that PTB messages can be dropped due to filtering even for
ICMPv6. There was also concern for the one (or more) RTTs
required for PMTUD to work, and for dealing with bogus
PTB
Owen DeLong wrote:
There should be no such thing as packet fragmentation in the current
protocol. What is needed is for people to simply configure things
correctly and allow PTB messages to pass as designed.
Owen
You are absolutely correct. Are you talking about IPv4 or IPv6?
Joe
Jeroen Massar wrote:
IPv4 without PMTUD, of course.
We are (afaik) discussing IPv6 in this thread,
That's your problem of insisting on very narrow solution
space, which is why you can find no solution and are
trying to ignore the problem.
It is a sender of a multicast packet, not you as
On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
3) For IPv6 packets between 1281-1500, break the packet
into two (roughly) equal-sized pieces and admit each
piece into the tunnel. (In other words,
Hi Brett,
-Original Message-
From: Brett Frankenberger [mailto:rbf+na...@panix.com]
Sent: Monday, June 04, 2012 9:35 AM
To: Templin, Fred L
Cc: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
https
On Sun, Jun 3, 2012 at 11:20 PM, Jimmy Hess mysi...@gmail.com wrote:
On 6/3/12, Jeroen Massar jer...@unfix.org wrote:
If one is so stupid to just block ICMP then one should also accept that one
loses functionality.
ICMP tends to get blocked by firewalls by default; There are
legitimate
Templin, Fred L wrote:
Also, when
IPv4 is used as the outer encapsulation layer, the 16-bit ID
field can result in reassembly errors at high data rates
[RFC4963].
As your proposal, too, gives up to have unique IDs, does that
matter?
Note that, with your draft, a route change between two
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Monday, June 04, 2012 12:06 PM
To: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
Also, when
IPv4 is used as the outer encapsulation layer, the 16-bit ID
field
Templin, Fred L wrote:
As your proposal, too, gives up to have unique IDs, does that
matter?
This is taken care of by rate limiting at the tunnel
No, I'm talking about:
Note that a possible conflict exists when IP fragmentation has
already been performed by a source host before the
On 2012-06-04 07:31, Jared Mauch wrote:
On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote:
On 4 Jun 2012, at 06:36, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by
how exactly?
Completely wrongly.
-Original Message-
From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp]
Sent: Monday, June 04, 2012 1:08 PM
To: Templin, Fred L; nanog@nanog.org
Subject: Re: IPv6 day and tunnels
Templin, Fred L wrote:
As your proposal, too, gives up to have unique IDs, does
Jeroen Massar wrote:
Tunnels therefor only should exist at the edge where native IPv6 cannot
be made possible without significant investments in hardware and or
other resources. Of course every tunnel should at one point in time be
replaced by native where possible, thus hopefully the folks
I just want to know if we can expect IPv6 to devolve into 1280 standard
mtu and at what gigabit rates.
The vast majority of hosts will still expect 1500, so
we need to find a way to get them at least that much.
Fred
fred.l.temp...@boeing.com
On 2012-06-04 14:26, Joe Maimon wrote:
Jeroen Massar wrote:
Tunnels therefor only should exist at the edge where native IPv6 cannot
be made possible without significant investments in hardware and or
other resources. Of course every tunnel should at one point in time be
replaced by
I just want to know if we can expect IPv6 to devolve into 1280 standard
mtu and at what gigabit rates.
1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
and process ICMPv6 Packet-Too-Big messages everything will just work.
This whole thread is about people who
On 2012-06-04 14:55, Templin, Fred L wrote:
I just want to know if we can expect IPv6 to devolve into 1280 standard
mtu and at what gigabit rates.
1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
and process ICMPv6 Packet-Too-Big messages everything will just work.
on it?
There are dramatically fewer IPv4 tunnels than IPv6 tunnels to the best of my
knowledge.
Why do you think a maturing IPv6 means less tunnels as opposed to more?
Because a maturing IPv6 eliminates many of the present day needs for IPv6
tunnels which
is to span IPv4-only areas
Jeroen Massar wrote:
If people want to use a tunnel for the purpose of a VPN, then they will,
be that IPv4 or IPv6 or both inside that tunnel.
Instead of having a custom VPN protocol one can do IPSEC properly now as
there is no NAT that one has to get around. Microsoft's Direct Access
Owen DeLong wrote:
Fail.
What, exactly are you saying is a failure? The single word here even in context
is
very ambiguous.
The failure is that even now, when tunnels are critical to transition, a
proper solution that improves on the IPv4 problems does not exist
And if tunnels do
PMTU-d probing, as recently standardizes seems a more likely solution.
Having CPE capable of TCP mss adjustment on v6 is another one. Being
able to fragment when you want to is another good one as well.
I'll take a) and c), but don't care so much for b).
About fragmenting, any tunnel ingress
On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:
Owen DeLong wrote:
Fail.
What, exactly are you saying is a failure? The single word here even in
context is
very ambiguous.
The failure is that even now, when tunnels are critical to transition, a
proper solution that improves
Maimon
Cc: nanog@nanog.org
Subject: Re: IPv6 day and tunnels
On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:
Owen DeLong wrote:
Fail.
What, exactly are you saying is a failure? The single word here even in
context is
very ambiguous.
The failure is that even now, when
Templin, Fred L wrote:
I'm not sure that a randomly-chosen skip value is even
necessary.
It is not necessary, because, for ID uniqueness fundamentalists,
single event is bad enough and for most operators, slight
possibility is acceptable.
Outer fragmentation cooks the tunnel egresses at high
On 2012-06-04 15:27, Joe Maimon wrote:
Jeroen Massar wrote:
If people want to use a tunnel for the purpose of a VPN, then they will,
be that IPv4 or IPv6 or both inside that tunnel.
Instead of having a custom VPN protocol one can do IPSEC properly now as
there is no NAT that one
What we need is World 1280 MTU day where *all* peering links are
set to 1280 bytes for IPv4 and IPv6 and are NOT raised for 24 hours
regardless of the complaints. This needs to be done annually.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
I kind of like the idea. I suspect that $DAYJOB would be less enthusiastic.
Owen
On Jun 4, 2012, at 5:13 PM, Mark Andrews wrote:
What we need is World 1280 MTU day where *all* peering links are
set to 1280 bytes for IPv4 and IPv6 and are NOT raised for 24 hours
regardless of the
Jeroen Massar wrote:
That indeed matches most of the corporate world quite well. That they
are heavily misinformed does not make it the correct answer though.
Either you are correct and they are all wrong, or they have a
perspective that you dont or wont see.
Either way I dont see them
Joe Maimon wrote:
pMTU has been broken in IPv4 since the early days.
It is still broken. It is also broken in IPv6. It will likely
still be broken for the forseeable future. This is
Relying on ICMP exception messages was always wrong for normal network
operation.
Agreed.
The proper
On Jun 4, 2012, at 5:33 PM, Masataka Ohta wrote:
Joe Maimon wrote:
pMTU has been broken in IPv4 since the early days.
It is still broken. It is also broken in IPv6. It will likely
still be broken for the forseeable future. This is
Relying on ICMP exception messages was always wrong
On Jun 4, 2012, at 5:21 PM, Joe Maimon wrote:
Jeroen Massar wrote:
That indeed matches most of the corporate world quite well. That they
are heavily misinformed does not make it the correct answer though.
Either you are correct and they are all wrong, or they have a perspective
On 2012-06-04 17:57, Owen DeLong wrote:
[..]
If you're going to redesign the header, I'd be much more interested
in having 32 bits for the destination ASN so that IDR can ignore IP
prefixes altogether.
One can already do that: route your IPv6 over IPv4 IPv4 has 32bit
destination addresses
On 6/4/12, Owen DeLong o...@delong.com wrote:
[snip]
Probing as you have proposed requires you to essentially do a binary search
to arrive
at some number n where 1280≤n≤9000, so, you end up doing something like
this:
[snip]
So, you waited for 13 timeouts before you actually passed useful
Well, IPv6 day isnt here yet, and my first casualty is the browser on
the wife's machine, firefox now configured to not query .
Now www.facebook.com loads again.
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is
On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon jmai...@ttec.com wrote:
Well, IPv6 day isnt here yet, and my first casualty is the browser on the
wife's machine, firefox now configured to not query .
Now www.facebook.com loads again.
Looks like a tunnel mtu issue. I have not as of yet traced
Joe Maimon wrote:
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is (not)
receiving them, etc.
The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels,
which means the best fix is ipv6 mtu 1280 on the
Cameron Byrne wrote:
#1 don't tunnel unless you really need to.
Tunnels are ipv4 only now?
#2 see #1
#3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has
a good implementation, but this does not solve MTU issues.
Because the initial connections are made just fine.
On Jun 3, 2012, at 7:38 PM, Joe Maimon jmai...@ttec.com wrote:
www.arin.net works and worked for years. www.facebook.com stopped June 1.
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
It doesn't fix the fragmentation issues. It assumes working PMTU.
For what it's
In message 4fcc11b2.2090...@ttec.com, Joe Maimon writes:
Well, IPv6 day isnt here yet, and my first casualty is the browser on
the wife's machine, firefox now configured to not query .
Now www.facebook.com loads again.
Looks like a tunnel mtu issue. I have not as of yet traced the
On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote:
Joe Maimon wrote:
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is (not)
receiving them, etc.
The culprit is the v6 tunnel, which wanders into v4
On 2012-06-03 20:26, bmann...@vacation.karoshi.com wrote:
On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote:
[..]
actually, to be safe, 1220.
That will work really well with the minimum IPv6 MTU being 1280 ;)
Greets,
Jeroen
On 6/3/12, Cameron Byrne cb.li...@gmail.com wrote:
On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon jmai...@ttec.com wrote:
[snip]
#5 According to the IETF, MSS hacks do not exist and neither do MTU
issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html
They couldn't be more wrong.
On 3 Jun 2012, at 20:40, Jimmy Hess mysi...@gmail.com wrote:
On 6/3/12, Cameron Byrne cb.li...@gmail.com wrote:
On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon jmai...@ttec.com wrote:
[snip]
#5 According to the IETF, MSS hacks do not exist and neither do MTU
issues
Joe Maimon wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Or was the fix incorporating the breakage into the basic design?
Yes.
Because IPv6 requires ICMP packet too big generated against
multicast, it is designed to cause ICMP implosions,
95 matches
Mail list logo
