I was a little surprised by this document when I read it. The title
is "An uniform format for IPv6 extension headers", and the abstract
reads as I'd expect. However, when we get to section 3 (Applicability)
"SHOULD" and "MUST" are used, *not* to require people to use a uniform
format for IPv6 exten
On Wed, Jul 28, 2010 at 03:55:44PM -0500, George, Wes E IV [NTK] wrote:
> [[WEG]] I refer you to Bert Manfredi's message
> http://www.ietf.org/mail-archive/web/ipv6/current/msg12042.html.
> The lack of a checksum is why I'm generally resistant to the idea
> of preserving immutability of this field
On Fri, Aug 07, 2009 at 04:06:16PM -0400, Christopher Morrow wrote:
> > 4,166,900,871 packets 0 dropped due to bad checksum
>
> neat! (I'm also going to see if I can get some stats from a wider set
> of hosts, but)
If routers check the IPv4 header checksum (which I think they are
supposed to
On Tue, Jul 28, 2009 at 05:00:22AM -0400, Christopher Morrow wrote:
> it's 10 years old, from a single network link, in what I suspect was
> VBNS+, so not even today's internet (scale or applications or users or
> traffic levels or uses)
People might want to check "netstat -s" - on some OSes it di
On Thu, Jul 02, 2009 at 12:40:20PM +0530, Vijayrajan ranganathan wrote:
> Is there a standard solution for this kind of problem?
On some OSes it is possible to control the host part of the
autoconfigured address by manually configuring a link local address
before the interface is brought up. The h
On Fri, Apr 04, 2008 at 03:01:16PM -0700, Brian McGehee wrote:
> Answer with it's link-local address, which is probably not the goal.
In that case use a Node Information Query for either the hostname
or list of addresses. KAME stacks support requests for the hostname,
which often proves useful. I
On Fri, Mar 14, 2008 at 01:43:15AM +0200, Pekka Savola wrote:
> While we're considering RFC3484 changes, here's one additional
> proposed modification to RFC3484 for Linux with ORCHID (RFC 4843) that
> is worth serious consideration. (Discussion on the best
> implementation choice(s) and glibc
On Wed, Oct 24, 2007 at 03:30:50PM +0100, [EMAIL PROTECTED] wrote:
> I don't think you understand the situation. There are loads of people
> with many years of deep IPv4 experience under their belt. They have
> gotten used to understanding networks and being right when they make
> design tradeoffs.
On Mon, Aug 27, 2007 at 03:53:22PM -0400, Suresh Krishnan wrote:
> >I would be curious how people feel about these choices if they also apply
> >to (as they should) IPv4 source routing.
> I think the problems, though overlapping, are completely different in
> magnitude. The problem with IPv4 sour
On Mon, Aug 20, 2007 at 01:43:19PM -0700, Bob Hinden wrote:
> We would like to get your comments on the following two choices:
>
> 1) Deprecate RH0 as specified in .
I would have originally supported option (2), because it would have
allowed RH0 to be used in a relatively harmless way. However, I
On Mon, Aug 20, 2007 at 11:54:29AM +0100, Tim Chown wrote:
> (http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary-02)
I note that the IPv6 tools.ietf.org seems to be down or inaccessable
since late last week. A nearby hop is returning no route to host
and address inaccessable messages.
> > If you've access to someone's machine and can twiddle parameters
> > of their IP stack, then RH0 isn't a big deal.
> I did not understand your point here.
> Are you trying to justify that RH0 are harmless regarding other kind
> of attacks ?
I think Joe was suggesting that if RH0 was useful to
> There seem to be many daily examples of very large numbers of client
> machines being controlled remotely to participate in activities that
> the owner/operators of those machines aren't aware of. If there's a
> hook available to turn RH0 processing back on, and RH0 is useful to
> the kin
> As RH0 was fully available on the IPv6 Internet 2 weeks ago, my
> conclusion (don't hesitate to challenge me on that, guys) is simply
> that there is perhaps just no correlation between RH0 and looking
> glass, i.e. they are not used for the same purposes / by the same
> people.
I agree - while
On Fri, May 11, 2007 at 02:16:41PM +0200, Guillaume Valadon /
wrote:
> Except some custom-made traceroute6 and KAME's implementation, I am
> not aware of such usage of RH0. What I mean here, is that deprecating
> RH0 won't harm anyone (except some reasearchers).
> Dis
On Fri, May 11, 2007 at 11:16:49AM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
> I believe we should rather return an ICMPv6 error. Even if we decide
> to deprecate type0 RH, there will be many non-updated systems for a
> certain period of time. Since there is at least one know popular
On Thu, May 10, 2007 at 05:49:14PM +0300, Pekka Savola wrote:
> On Thu, 10 May 2007, Jeroen Massar wrote:
> >As such, when you are a transit provider, and you have on the edges of
> >your network some vulnerable hosts, those hosts can be used to apply
> >this attack to your network.
> >The documen
On Mon, Apr 30, 2007 at 05:43:04PM -0700, james woodyatt wrote:
> I
> further recommend the draft standards be amended to require that RH0
> be rejected with an ICMP error when received at the first destination
> and dropped silently in all other cases. This will allow operators
> to ident
On Fri, Apr 27, 2007 at 10:19:01AM +0100, Jeroen Massar wrote:
> This 'problem' can be solved with looking glass websites, not which such
> an obvious security problem as RH0.
Surely the number of looking glass websites are a clear sign of a
difficency in IPv4? (Also, having to parse input to web
On Thu, Apr 26, 2007 at 12:16:46PM +0200, Brian E Carpenter wrote:
> Excuse my ignorance, but have the following three rules ever been
> considered?
>
> 1. The list of addresses in an RH0 MUST NOT include the packet's source
> address.
> 2. The same address MUST NOT occur more than once in an RH0
On Wed, Apr 25, 2007 at 05:39:40PM -0700, Bob Hinden wrote:
> 1) Deprecate all usage of RH0
> 2) Recommend that RH0 support be off by default in hosts and routers
> 3) Recommend that RH0 support be off by default in hosts
> 4) Limit it's usage to one RH0 per IPv6 packet and limit the number
>
On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote:
> I think this is not a solution. The problems of routing header type 0 well
> know by the community since long time. This has been documented for more
> than 2-3 years know (raised 4 years ago). Are there any consensus, that
> type
On Sat, Jan 20, 2007 at 03:37:51PM +0900, Syed Obaid Amin wrote:
> I am new to NS-2 and doesnt know much about it. I have to simulate an
> IPv6 network on NS-2 but unable to find any clue so far.
What aspects of IPv6 do you want to simulate? The addressing used
in NS is usually kind-of abstracted,
On Thu, Nov 02, 2006 at 03:54:08PM +0530, kernel learner wrote:
> In IPv6 whenever a NS packet is received,
> and if the target address is link local, then second 16 bits from lsb side
> are fileed with interface index. and while sending NA as reply those bits in
> target address are made zero. Why
On Tue, Jan 24, 2006 at 01:24:59PM -0500, Brian Haberman wrote:
> The WG Last Call has passed on this with two substantive comments.
> The following is the proposed changes to -13 to address them. Please
> voice your support or disagreement with these changes.
Looks good to me too.
On Thu, Jan 05, 2006 at 08:40:23AM -0500, Brian Haberman wrote:
> This change was made to address DoS concerns raised with having
> the default behavior to respond to queries to the All-Nodes address.
Echo requests already have this problem. I have a feeling that it
makes no sense to drop queries
On Wed, Jan 04, 2006 at 04:08:01PM -0500, Brian Haberman wrote:
> I have integrated most of the changes I proposed to the ICMP Names
> draft. After my previous note on the subject, I had a lot of input on
> the tunnel endpoint text and determined that there was not consensus to add
> it to
On Mon, Nov 21, 2005 at 12:54:37AM +0800, Li Defeng wrote:
> After then I run ipconfig, find that I have already have thress
> IPv6 addresses, one for the wireless link, one for Tunnel adapter
> Teredo Tunneling Pseudo-Interface,Tunnel adapter Automatic Tunneling
> Pseudo-Interface, the result of I
On Wed, Nov 16, 2005 at 01:59:10PM -0500, Brian Haberman wrote:
> Issue 1: Restrict operation of the protocol to link-local use.
>
> Resolution:
> The consensus is to retain the more flexible multi-hop capability.
> An additional sentence or two will be added to the Security
> Consi
On Wed, Oct 19, 2005 at 05:36:48PM +0800, zhangjian 24185 wrote:
> Dear all,
>
> I have submitted the draft, draft-jian-ipv6-meaheader.The purpose
> of this document is to introduce a measurement header. Measurement
> header is a new type of IPv6 extended header used for network
> measurement. The
On Fri, Apr 22, 2005 at 06:09:13AM -0400, Bound, Jim wrote:
> The flowlabel must be restored end-to-end, but can be mutable in route
> over the network per 3697.
I guess this means that if an ICMP error message is generated then
the chunk of the original packet quoted by the ICMP error should
refl
On Mon, Mar 28, 2005 at 06:20:19PM -0800, Bill Fenner wrote:
>http://[v6.fe80::cafe:f00d_de0]/ .
Isn't using "v6." here a bit misleading? RFC 3986 seems to say that
the version flag doesn't indicate the IP version, it incidates the
version of the literal format that follows.
David.
-
On Tue, Mar 01, 2005 at 03:51:34PM +0200, Jari Arkko wrote:
> On the other hand, if the problem is in bad drivers (as Bill points
> out), this may be a different issue. I guess part of the problem is
> that for plain old IPv4 usage multicast features in NICs and the
> drivers don't get tested well,
On Fri, Dec 24, 2004 at 07:58:30AM -0800, Yudi wrote:
> I try to setup it with sysctl (in freeBSD) with this syntag :
> net.inet6.ip6.auto_flowlabel=0 (for deactivate)
> and
> net.inet6.ip6.auto_flowlabel=1 (for activate)
> But I saw with ethereal, the header still no different.
The auto_flowlabel
On Wed, Aug 18, 2004 at 02:51:49PM -0500, [EMAIL PROTECTED] wrote:
> 1) SHOULD
> 2) MAY
> 3) Any of them is fine for you.
MAY...
David.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: htt
35 matches
Mail list logo
