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.
In message m24ncmaozs.wl%ra...@psg.com, 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
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 we
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
* 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 in
Brian E Carpenter brian.e.carpen...@gmail.com 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 j...@jlc.net
Hello,
Has anybody had a chance to review it?
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy
thank you,
Regards,
Hosnieh
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
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
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
On Jun 24, 2013, at 10:39 PM, Brian E Carpenter brian.e.carpen...@gmail.com
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
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 Tue, Jun 25, 2013 at 12:27 PM, Templin, Fred L fred.l.temp...@boeing.com
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
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 similarly
for v4.
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 bytes MTU on all
On Jun 25, 2013, at 13:13 , Randy Bush ra...@psg.com 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 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
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 compellingly awful, but true to
On 26/06/2013 11:08, james woodyatt wrote:
On Jun 25, 2013, at 13:13 , Randy Bush ra...@psg.com 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
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
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 name on an
On Tue, 25 Jun 2013 16:36:51 +
Christian Huitema huit...@microsoft.com 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
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
I have the following suggestion:
IPv6 hosts can try to gain knowledge of the path MTU to a destination. If the
path blocks or filters PMTUD etc, then the host should revert to 1280 bytes
else the hosts can use a higher packet size.
This mechanism would make Fragment header redundant anyway
The
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 under a
In message 0f21d0e7-b884-4cc1-b808-e0c644751...@yahoo.com, Usman Latif writes
:
I have the following suggestion:
IPv6 hosts can try to gain knowledge of the path MTU to a destination. If the
path blocks or filters PMTUD etc, then the host should revert to 1280 bytes
else the hosts can use
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
26 matches
Mail list logo
