* Tore Anderson:
* Florian Weimer
And I see no functional difference between the gateway and the host
generating the fragment ID, except that the latter approach seems to
require network-wide software updates currently.
A stateless translator does not keep track of the PMTU for the IPv4
be made to
work.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF IPv6
* Florian Weimer:
Actually, atomic fragments aren't the problem, but the technology that
serves as a justification for them. [...]
This argument turns out to be entirely wrong. Sorry about that.
I'm still extremely bothered by atomic fragments. Their use case seems
to be something like
of the
flow label header in transit, so I really doubt that there are any such
applications.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
software updates currently.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF
preference would be to kill this whole atomic fragment stuff before
it goes any further.
In case this isn't obvious, this is my feeling as well.
I'm still looking for a justification for the complexity of preserving
this protocol aspect, but I doubt there is one.
--
Florian Weimer
to send the ICMP message.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF
* Fernando Gont:
b) Processing of atomic fragments as non-fragmented traffic.
Is this even possible? The presence of an additional extension header
necessarily triggers additional packet processing, doesn't it?
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH
* Fernando Gont:
On 01/04/2012 05:19 AM, Florian Weimer wrote:
Why should you drop in this case, when it's trivial to process these
fragments safely, with no side effects??
Do we really know that adding a fragment header to all outgoing packets
does not cause them to be rejected
don't
permit that, anyway).
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
-)
If a packet is actually destined to the IPv4 world (and hence needs to
go through a translator), it will need to cross one translator, or
another... but *some* translator.
Couldn't it be translated back to IPv6? Then there could be an
IPv6-only path between sender and recipient.
--
Florian
* Fernando Gont:
Hi, Florian,
On 12/23/2011 07:46 AM, Florian Weimer wrote:
That aside, I don't know whether e.g. NAT64 or the like used this
(.e.g, whether they are used for transition technologies as envisioned
in RFC 2460). However, it might also be the case that such atomic
fragments
* Fernando Gont:
Hello, Florian,
On 12/20/2011 07:00 AM, Florian Weimer wrote:
cut here
IPv6 allows packets to contain a Fragment Header, without the packet
being actually fragmented into multiple pieces. Such packets
typically result from hosts that have received
.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF IPv6 working group mailing
, but
this is broken. a) is consistent with optional PMTUD, so it seems
the sanest choice.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
be an ugly kludge.)
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF
case. Sequential scanning used to trigger it. I
suspect that router capacities for ARP processing have since increased.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe
* Ray Hunter:
Are 2^24 interface identifiers small enough that every implementation
could simply provide enough resources (for ND) to cope with all
addresses being in play simultaneously?
You'd need per-interface and per-VLAN tables. I don't think that's
feasible.
--
Florian Weimer
things differently with IPv6, but customers
will probably not like it.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
?
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
IETF IPv6 working group mailing list
of processing power and state
per identified endpoint. But without that, you have zero chance against
a local attacker.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe
* Brian E. Carpenter:
Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source port, dest port, protocol #}.
This is relatively trivial at line speed in IPv4 since
these things are at fixed locations
* Rob Austein:
I think the IETF should get out of the way and let the MLS people have
their hop-by-hop option and Informational document.
As long as there's no expectation that it works on the open Internet,
sure. 8-)
IETF
23 matches
Mail list logo
