Joe Touch wrote:
Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.
But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which there is no
consensus.
It certainly does not.
The following
Joe Touch wrote:
Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.
But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which there is no
consensus.
That is, though your draft claims to more
On 8/13/2012 2:45 AM, Masataka Ohta wrote:
Joe Touch wrote:
Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.
But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which there is no
Joe Touch wrote:
Hi,
RFC2765 specifies that translators can merely copy the
low-order bits of the field.
Yes, but this is not compatible with RFC791.
Then, which should we revice? RFC791, RFC2765 or both?
2765.
Is it a consensus of IETF?
Note that it also imply revising RFC2460,
Joe Touch wrote:
RFC2765 specifies that translators can merely copy the
low-order bits of the field.
Yes, but this is not compatible with RFC791.
Then, which should we revice? RFC791, RFC2765 or both?
Without such a decision, there is no point to publish something
based on RFC791 and is
Hi,
On 8/7/2012 12:26 AM, Masataka Ohta wrote:
Joe Touch wrote:
RFC2765 specifies that translators can merely copy the
low-order bits of the field.
Yes, but this is not compatible with RFC791.
Then, which should we revice? RFC791, RFC2765 or both?
2765.
There is no useful way to
Joe Touch wrote:
Translators violate RFC791. They cannot merely copy the
low-order bits of the field, since that is insufficiently
unique, and isn't specified as being generated at the
IPv6 source in compliance with IPv4 requirements.
RFC2765 specifies that translators can merely copy the
On 8/3/2012 4:19 PM, Masataka Ohta wrote:
Joe Touch wrote:
Translators violate RFC791. They cannot merely copy the
low-order bits of the field, since that is insufficiently
unique, and isn't specified as being generated at the
IPv6 source in compliance with IPv4 requirements.
RFC2765
Joe Touch wrote:
Or, are 6 to 4 translators are required to rate limit and
drop rate-violating packets to make the stateless
translators full of states.
I would expect that the translator would be responsible
for this, though
Do you mean translators must rate limit, or translators
violate
On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:
Joe Touch wrote:
Or, are 6 to 4 translators are required to rate limit and
drop rate-violating packets to make the stateless
translators full of states.
I would expect that the translator would be responsible
for this, though
Do you
Hi,
On 6/20/2012 5:57 PM, Masataka Ohta wrote:
Though the ID states:
This
document underscores the point that not only is reassembly (and
possibly subsequent fragmentation) required for translation, it can
be used to avoid issues with IPv4 ID uniqueness.
according to
Though the ID states:
This
document underscores the point that not only is reassembly (and
possibly subsequent fragmentation) required for translation, it can
be used to avoid issues with IPv4 ID uniqueness.
according to RFC2765, which does not need port numbers for
address mapping:
Joe Touch wrote:
draft-generic-v6ops-tunmtu-03.txt
to fragment IPv6 packets by intermediate routers should be
very interesting to you.
It is aware of our IPv4-ID doc, and consistent with it.
What?
When the DF is ignored, the ID field is rewritten - i.e.,
If the ID field could be
Joe Touch wrote:
It is a fair action by innocent providers.
It is a violation of standards. They may do it innocently, but it's
still a violation.
You misunderstand standardization processes.
Standards remain so until revoked explicitly. Common use does
not itself revoke a standard - it
I will include a response to the rest of this in my summary of the last
call concerns. Regarding your last point:
On 6/18/2012 5:39 AM, Masataka Ohta wrote:
...
PS
While your draft is rather harmful than useless, I'm fine
if the following point of the draft:
Originating sources MAY
On 6/18/2012 5:09 AM, Masataka Ohta wrote:
Joe Touch wrote:
draft-generic-v6ops-tunmtu-03.txt
to fragment IPv6 packets by intermediate routers should be
very interesting to you.
It is aware of our IPv4-ID doc, and consistent with it.
What?
I looked more closely, and the doc is
Joe Touch wrote:
While your draft is rather harmful than useless, I'm fine
if the following point of the draft:
Originating sources MAY set the IPv4 ID field of atomic
datagrams to any value.
is changed to:
Originating sources MUST set the IPv4 ID field of atomic
Joe Touch wrote:
Again, this document doesn't change the current situation. Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing standards.
While IETF is not a protocol police and
On Jun 15, 2012, at 11:50 PM, Masataka Ohta wrote:
Joe Touch wrote:
Again, this document doesn't change the current situation. Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing
On Jun 15, 2012, at 10:54 PM, Masataka Ohta wrote:
Joe Touch wrote:
That is not an innocent action.
It is a fair action by innocent providers.
It is a violation of standards. They may do it innocently, but it's
still a violation.
You misunderstand standardization processes.
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators often clear DF bit and
end users are happy with it, because, today,
Joe Touch wrote:
Hi,
Hi,
But, then,
Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
makes most, if not all, IPv4 hosts non compliant if MSL=2min.
This is already
Masataka,
On 6/15/2012 3:48 AM, Masataka Ohta wrote:
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators often clear DF bit
Hi, Masataka,
On 6/15/2012 5:01 AM, Masataka Ohta wrote:
Joe Touch wrote:
Hi,
Hi,
But, then,
Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
makes most, if not
Joe Touch wrote:
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators often clear DF bit and
end users are happy with it,
Masataka,
On 6/15/2012 6:54 PM, Masataka Ohta wrote:
Joe Touch wrote:
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators
Joe Touch wrote:
That is not an innocent action.
It is a fair action by innocent providers.
It is a violation of standards. They may do it innocently, but it's
still a violation.
You misunderstand standardization processes.
That innocent operators must violate some standard means
the
Kuari wrote:
On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote:
On Sat, 2 Jun 2012, Masataka Ohta wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and
Hi,
On 6/3/2012 12:12 PM, Masataka Ohta wrote:
C. M. Heard wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and any
router fragmenting such a
Some further points...
On 6/1/2012 7:45 PM, Masataka Ohta wrote:
Joe Touch wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
The recommendation in this doc - that such sources MUST rate-limit - is
to
--
No man is an island, But if you take a bunch of dead guys and tie them
together, they make a pretty good raft.
--Anon.
On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote:
On Sat, 2 Jun 2012, Masataka Ohta wrote:
Existing routers, which was relying on ID uniqueness of atomic
C. M. Heard wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and any
router fragmenting such a packet was and is non-compliant with
the relevant
On Sat, 2 Jun 2012, Masataka Ohta wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and any
router fragmenting such a packet was and is non-compliant
C. M. Heard wrote:
My one reservation is that I do not think it is strictly necessary
to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
datagrams.
Do you mean
Sources of non-atomic IPv4 datagrams MUST rate-limit their output
to comply with the ID uniqueness
On 6/1/2012 5:03 PM, Masataka Ohta wrote:
C. M. Heard wrote:
My one reservation is that I do not think it is strictly necessary
to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
datagrams.
Do you mean
Sources of non-atomic IPv4 datagrams MUST rate-limit their
Joe Touch wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
The recommendation in this doc - that such sources MUST rate-limit - is
to comply with the ID uniqueness requirements already in RFC791 that
this
On Thu, 31 May 2012, The IESG wrote:
The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'Updated Specification of the IPv4 ID Field'
draft-ietf-intarea-ipv4-id-update-05.txt as Proposed Standard
The IESG plans to make a
37 matches
Mail list logo
