my take on this is that, for non-final fragment, the packet size must
not be smaller than 1280 bytes. there's no valid use for smaller
fragments (unless you have special network with MTU 1280).
I agree to the solution. If we get more people talking about the need
for this, we can
On 2007-05-17 03:29, Joe Abley wrote:
On 16-May-2007, at 18:54, Dow Street wrote:
It may not be the mechanism itself that is the inherent problem, but
rather the operational use model. In this case, disabling by default
and filtering when RH0 is turned on allows for careful investigation
On Wed, 16 May 2007, Vlad Yasevich wrote:
As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?
Dunno about that, but I guess an Updates: 4294 (IPv6 Node
Requirements) would be in order.
--
Pekka
Brian Haberman wrote:
While it would be useful to update 3542, I don't think it is necessary.
It is out-of-date given that it says the Type 0 routing header is the
only one defined (it isn't). However, I don't see the benefit of
revising that spec *just* for this.
Perhaps we should simply
Hi,
Jun-ichiro itojun Hagino 2.0 wrote:
my take on this is that, for non-final fragment, the packet size must
not be smaller than 1280 bytes. there's no valid use for smaller
fragments (unless you have special network with MTU 1280).
I tend to disagree. I do think
On 16-May-2007, at 22:11, Iljitsch van Beijnum wrote:
On 17-mei-2007, at 3:29, Joe Abley wrote:
There is an argument that the right approach to facilitate source
routing experiments is to deprecate RH0, and define a new type of
routing header which is, from the outset, disabled by
On Wed, May 16, 2007 at 03:54:48PM -0700, Dow Street wrote:
I think the new draft is too extreme in its mitigation approach, and
would favor the disable by default option instead.
I think the new draft is too soft in it's mitigation approach, and would
favour language that more strongly
Jun-ichiro itojun Hagino 2.0 wrote:
As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?
we may want to remove references to rthdr0, but section 7 (Routing
Header) may be useful for rthdr7
Hi Ryan,
Good point about including the whole sentence; mea culpa! :^\
On Wed, May 16, 2007 at 05:09:34PM -0500, Tim Enos wrote:
In section 4.2, IMO it would seem good to see a brief justification of
the statement: filtering based on the presence of any
Routing Headers on IPv6 routers,
Le jeudi 17 mai 2007, Vlad Yasevich a écrit :
As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?
And then:
1/ Are inet6_rth_space() and inet6_rth_init() supposed to fail with
type 0?
2/ What is
On Wed, May 16, 2007 at 03:54:48PM -0700, Dow Street wrote:
I think the new draft is too extreme in its mitigation approach, and
would favor the disable by default option instead.
I think the new draft is too soft in it's mitigation approach, and would
favour language that more strongly
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : IP Version 6 over PPP
Author(s) : S. Varada, et al.
Filename:
Dow,
Dow Street wrote:
I think the new draft is too extreme in its mitigation approach, and
would favor the disable by default option instead.
Underlying this debate seems to be the question of whether *any* form of
source routing is ok / worthwhile. I'm curious how much of the RH0 FUD
is
After reading draft-ietf-ipv6-deprecate-rh0-00.txt, I found several
problems:
- the draft mentions serious security implications that can be
exploited
without explaining what those are
- the draft deprecates the routing header type 0 without explaining
what deprecation entails
- the
14 matches
Mail list logo
