Hi
On 9/4/2013 4:28 AM, Ole Troan wrote:
Fernando,
would that be other nodes than yourself and nodes on the same link
as yourself?
I guess in some scenarios it might be tricky.
For instance, even with link-local only multicast (as that used for
ND), you can send a packet to a link-local
Hi
I'm not sure if this attack is all that serious since there is
always an RPF check for multicast.
As it says in the draft:
It should be noted that if the multicast RPF check is used (e.g.
to prevent routing loops), this would prevent an attacker from
forging the Source
Hi
Interesting draft. I need to think more about it, but I have a
comment below.
On 3/29/2013 2:52 AM, Mark Smith wrote:
Hi Carsten,
Thanks very much for your review and comments.
- Original Message -
From: Carsten Bormann c...@tzi.org
To: Mark Smith markzzzsm...@yahoo.com.au
Cc:
On 2/7/2013 9:26 AM, Alexandru Petrescu wrote:
Le 07/02/2013 13:49, Erik Hugne a écrit :
On Thu, Feb 07, 2013 at 11:44:22AM +0100, Alexandru Petrescu wrote:
Also, the implementation of that dropping may not be that
straightforward as at a quick first sight.
A stack presented with a packet
On 11/19/2012 6:57 PM, Liubing (Leo) wrote:
Hi, all
This is not talking about a new idea. The Parameterized IP-Specific
configuration comes from the 6renum WG item, see
http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-04#page-11
The draft is under 6renum WGLC, according to the
On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
On Tue, Aug 14, 2012 at 4:09 AM, mohamed.boucad...@orange.com wrote:
Dear all,
I'm initiating this thread in the hope of understanding the
objections from the 6man WG and hopefully to make some progress for
this document. To initiate the
On 6/27/2012 10:13 AM, Kerry Lynn wrote:
Greetings,
RFC 3484 section 3.1 defines subnet-local (0x03) multicast scope, but
later RFC 4291 section 2.7 defines this multicast scope value as reserved.
Can I ask if the later interpretation is the correct one?
I ask in the context of e.g.
On 5/14/2012 1:50 PM, Lee, Yiu wrote:
Hi Brian,
Sorry for getting back late. I read Bert's answers to your questions. His
answers are inline with my answers. Most information are statically
configured. For example: Ch1 is statically configured to 224.1.2.3 via OOB
mechanism. If the STB is IPv4
On 2/29/2012 2:10 PM, Stig Venaas wrote:
[...]
I think the main reason OpenBSD and NetBSD don't support SSM is
Apple's IPR claim. Without SSM support, there is little reason to
support MLDv2.
I got some questions about this. See
http://www.ietf.org/ietf-ftp/IPR/APPLE-SSM.txt
See also e.g
On 2/29/2012 1:17 PM, Behcet Sarikaya wrote:
On Wed, Feb 29, 2012 at 2:42 PM, Fernando Gontfg...@si6networks.com wrote:
On 02/29/2012 11:38 AM, Simon Perreault wrote:
On 2012-02-28 08:12, Jeroen Massar wrote:
I was wondering, if anybody had a rough idea how many MLDv1-only
listeners are
On 2/28/2012 5:12 AM, Jeroen Massar wrote:
Hi,
I was wondering, if anybody had a rough idea how many MLDv1-only
listeners are still out there in the wild. My assumption by now is that
current code out there (thus not stuff that has been up and running and
never upgraded for the last 5 years
On 9/20/2011 2:03 AM, Iljitsch van Beijnum wrote:
On 20 sep 2011, at 9:58, sth...@nethelp.no wrote:
For pt2pt SDH links you want /127 to avoid the ping-pong problem,
not /126.
That's nice (as long as your routers ignore the all zeros anycast address), but
the question was: how do we write
Wes Beebee (wbeebee) wrote:
I support this effort as I think it will future proof extension
headers as far as stateful firewalls are concerned - but what I'm
interested in is finding out how much demand for new extension headers
there is out there - and what those new extension headers would be.
Suresh Krishnan wrote:
Hi Remi,
On 10-04-16 05:44 AM, Rémi Després wrote:
Hi all,
Thanks to James for the pointer to draft-krishnan-ipv6-exthdr-08.
I don't know exactly what the status of draft-krishnan-ipv6-exthdr-08
is today, but it this proposal has IMHO to become quickly a
Regarding discussion on whether this applies to routers
or hosts and devices that are hosts on some interfaces
and routers on others.
It seems obvious that if it is only for inter-router
links, then it must be between devices that act as
routers on that link. Whether they have other interfaces
Fred Baker wrote:
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize that
perhaps the first you tried actually works.
My first point is that if you don't
Brian E Carpenter wrote:
...
My second point is that assumptions like the best path is through a
prefix we both use are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from assume both users are using the same
Scott Brim wrote:
Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in
Brian Haberman wrote:
All,
I would like to gauge the WG's opinion on adopting
draft-arkko-ipv6-iana-routing-header-00 as a 6MAN WG document. All
comments, for or against, should be sent to the mailing list or the
chairs by September 15th, 2009.
I want to see it adopted,
Stig
I'm in favour
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Joel Jaeggli wrote:
I did this for the ietf ids sensor and I haven't see any having run it
since noon.
udp[6:2] == 0
I would be interested in some statistics on IPv4 multicast, since I'm
working on IPv4 - IPv6 multicast translation. I think it's more common
to not use checksums for multicast.
Gorry Fairhurst wrote:
Rémi Denis-Courmont wrote:
[...]
Also, it might be worth to have an socket API consideration appendix...
Yes, it would need a small API update to work - this can be described if
people want to progress this.
Just a socket option would be enough. I kind of feel like
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
the main case where this isn't the case, is
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
Gorry Fairhurst wrote:
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time
Mark Andrews wrote:
In message [EMAIL PROTECTED], Thomas Narten
writes:
I'm not involved in this in detail, so I may be off base, but my
understanding is that the advanced API has not been picked up by Open
Group because its members didn't support doing so -- they just didn't
see a need to.
Thomas Narten wrote:
[...]
RH0 has been part of IPv6 for more than a decade. Remind of _who_ has
used it or is using it, and what critical applications take advantage
of it. I believe the answer to the question is pretty much the empty
set. That is what I mean there being no use cases.
I'm not
Hemant Singh (shemant) wrote:
Please see in line below with hs
-Original Message-
From: Ralph Droms (rdroms)
Sent: Friday, June 29, 2007 10:26 AM
To: JINMEI Tatuya /
Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh (shemant)
Subject: Re:
Rémi Denis-Courmont wrote:
On Tue, 13 Mar 2007 16:23:23 +0900, JINMEI Tatuya / 神明達哉
[EMAIL PROTECTED] wrote:
I thought I also pointed out
the available space might not be that large since it's an 'int' field
(which may be 16-bit long).
Wow... is there any implementation with a 16-bits
Ralph Droms wrote:
Just as a general intuition, I'm concerned that the IPv6 suite is becoming
less careful over time about the use of soft state inferred from snooping
various protocol interactions. IMHO, inferring soft state is OK, as long as
that state is an optimization and not a requirement
Bernie Volz (volz) wrote:
I would think that how an address is assigned shouldn't enter into this.
I can't see that it matters.
What really matters is the lifetimes associated with the address. The
longest lifetime address is probably the best to use since it is the
most stable. [Ignoring
Rémi Denis-Courmont wrote:
Hello,
On Wed, Oct 18, 2006 at 04:07:15PM -0400, Suresh Krishnan wrote :
I have submitted a draft requesting a standard format for IPv6
extension headers. I would appreciate any comments on it.
I think I don't understand why one would need new extension
Fred Baker wrote:
On Oct 19, 2006, at 3:53 AM, Su Thunder wrote:
I don't think your comment is a problem. Whether a block of memory is
payload or an extension header is determined by the Next Header value
of the immediately preceding header, not whether the extension header
is known or
Rémi Denis-Courmont wrote:
Hello,
Le Lundi 29 Mai 2006 13:23, Arifumi Matsumoto a écrit :
- Teredo is defined. (RFC4380)
Teredo should have less priority than 6to4 and IPv4
considering its communication overhead and reliability ?
Also, this value below conforms to Windows.
On Thu, Dec 01, 2005 at 11:15:50PM +, António Amaral wrote:
Dear All,
After draft-ietf-pim-sm-bsr-05.txt there is a section
3.5. Unicasting Bootstrap Messages to New and Rebooting
Routers
To allow new or rebooting routers to learn the RP-Set
quickly, when a
Hello message
On Sun, Nov 27, 2005 at 08:00:32PM -0800, Vishwas Manral wrote:
Hi Fred,
Good point. I agree, however a bigger limit would provide more
protection, besides a lot of extension headers may not be valid in most
cases, so TCP headers would come within the 800 bytes. Having a
configurable
is there a problem with doing ND?
Stig
Thanks again,
Vishwas
-Original Message-
From: Ole Troan [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 11:55 AM
To: Vishwas Manral
Cc: Stig Venaas; IPv6
Subject: Re: draft-ietf-ipv6-2461bis-05
Vishwas,
You said There is no difference
On Thu, Nov 17, 2005 at 02:21:01AM -0800, Vishwas Manral wrote:
Hi,
While going through the draft, I noticed there is no talk of tunneled ND
message in the entire draft.
The draft states: -
By setting the Hop Limit to 255, Neighbor Discovery is immune to
off-link
On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote:
Hi Janos,
I think that is the minimum Link MTU and not the smallest size non-last
fragment.
Can you point me to the RFC/ draft which says what you stated?
Yes, I believe that is the minimum link MTU. So, obviously one
?
Thanks,
Vishwas
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian E Carpenter
Sent: Friday, November 25, 2005 4:25 PM
To: Stig Venaas
Cc: ipv6@ietf.org
Subject: Re: IPv6 and Tiny Fragments
Stig Venaas wrote:
On Fri, Nov 25, 2005 at 12:53:37AM
On Fri, Nov 25, 2005 at 12:11:18PM +0100, Mohacsi Janos wrote:
On Fri, 25 Nov 2005, Vishwas Manral wrote:
Hi Mohacsi,
LWAPP encapsulation, IPv6-in-IPv6 etc.
I have to study LWAPP encapsulation - currently I have no opinion. In the
IPv6-in-IPv6 encapsulation It is completely
On Fri, Nov 25, 2005 at 12:35:27PM +0100, Mohacsi Janos wrote:
[...]
You halving approach not very useful for 9K packets, which is tend to be
common on GE and 10GE.
Just an example. Let's say you need say a minimum of 8 fragments to
make sure each fragment = path MTU (M). The obvious thing to
On Thu, Aug 11, 2005 at 03:59:11PM +0100, Tim Chown wrote:
On Thu, Aug 11, 2005 at 04:51:07PM +0200, Stig Venaas wrote:
Also worth checking if there are address selection problems that 3484
doesn't address.
Like selecting privacy addresses?
My feeling is that it's sufficient to disable
So far two principal solutions have been suggested, RAs and DHCP. If
people want to work on solutions we could possibly look into both of
these.
Some issues have already been mentioned on this list. Another issue
which was brought up in dhc wg, is that the policy is a host global
config, not per
On Wed, Aug 10, 2005 at 05:24:23PM +1000, Greg Daley wrote:
[...]
I'd suggest that if preferences are all that's needed, then the
function matches that for which the options are used now.
I agree that if only prefix preference is needed (possibly also
v4 vs v6), then it seems obvious to learn
On Tue, Aug 09, 2005 at 05:57:15PM +0900, Arifumi Matsumoto wrote:
Sorry for my late comment.
This is what I told Tim after dhc session, though.
On 2005/08/03, at 16:33, Francis Dupont wrote:
In your previous mail you wrote:
In a managed DHC environment, privacy addresses can be
RFC 3484, and implementations thereof, allows for a sysadmin to
configure address selection policy on a single host. I think this is
useful, and I suppose also the wg since the RFC was published. One
typical example might be preferring IPv4 over IPv6.
If I as a site administrator want all the
On Tue, Aug 02, 2005 at 06:49:50PM +0100, Tim Chown wrote:
Hi,
I raised this question today but we were short of time.
My concern is that in an enterprise deployment, I might want to avoid the
complexity of privacy addresses (from the management perspective).
Right, I'm not sure if that
On Tue, Aug 02, 2005 at 11:20:11PM +0200, Iljitsch van Beijnum wrote:
On 2-aug-2005, at 15:41, Tony Hain wrote:
I choose not to try to get to the mic, but on the debated
requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set
On Tue, Aug 02, 2005 at 06:30:07PM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
[...]
Even if I were to choose to use IPv6 for some reason, it seems I'd be
just happy with ULAs for such purposes, and then the (revised) default
address selection algorithm seems to suffice (and so we
On Wed, Jul 27, 2005 at 09:00:00PM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
On Sat, 23 Jul 2005 14:01:10 +0900 (JST),
[EMAIL PROTECTED] said:
| Here is the first cut at an agenda for the IPv6 working group session at
| the Paris IETF. Please review and send us comments,
On Tue, Jul 26, 2005 at 08:41:39PM +1200, Perry Lorier wrote:
I'd like to suggest a two phased development approach, based on whether
layer 2 can be assumed to fully support the larger MTUs or not (I think
the following is also probably a summary of the couple of threads of
discussion in
Please don't send HTML, hard for me to read and quote.
Clients should definitely do an MLD join for this group (just as they
should for the solicited multicast address used for ND). My experience
is also that clients do join both the solicited and the name-lookup.
I would be interested to hear of
On Mon, Jul 11, 2005 at 05:44:20PM -0400, Brian Haberman wrote:
[...]
The main, current benefit of MLDv2 is to support source-specific
multicast
(SSM). However, the NDP use of multicast is non-SSM (ASM or any-source
multicast) and does not need MLDv2 capability in order to function
On Mon, Jul 11, 2005 at 06:16:03PM -0400, Brian Haberman wrote:
On Jul 11, 2005, at 18:06, Elwyn Davies wrote:
My understanding that as well as a reference to MLDv2 we would need to
mention that if any of the routers are 'legacy' that support only
MLDv1, then any MLDv2 routers would have
On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote:
Tim
Wouldn't an update to a policy table be enough to resolve the problem?
Yes, but isn't it best that the default policy does the right thing?
Else everyone with ULA doing global multicast will need to update their
policies. Of
On Thu, May 12, 2005 at 02:46:10PM -0700, Arun Thulasi wrote:
Hello All,
This is a request to review and comment on the internet draft available
at
http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filtering-rules-00.txt
The draft is written to explain a set of behaviors in
On Tue, Mar 08, 2005 at 11:18:41AM -0500, Margaret Wasserman wrote:
[...]
Reverse (address-to-name) queries for IPv6 Local addresses must
not be sent to name servers for the global DNS, due to the load that such
queries would create for the authoritative name servers for the
ip6.arpa zone.
On Thu, Sep 30, 2004 at 03:02:46PM +0200, Francis Dupont wrote:
In your previous mail you wrote:
after we experimented a lot with (especially short) lifetimes on various
= short prefix lifetimes are not the common case: prefix lifetimes
are at least in months and are announced in days.
On Wed, Aug 18, 2004 at 02:51:49PM -0500, [EMAIL PROTECTED] wrote:
[...]
In your opinion (no reasoning please), the rate limiting
configuration per-interface in the ICMPv6 spec should be a
1) SHOULD
2) MAY
3) Any of them is fine for you.
2 MAY
Stig
On Thu, Aug 19, 2004 at 07:59:00AM -0400, Bound, Jim wrote:
The key is the ongoing debate of stateless vs stateful and members
working their agendas for their products. The bottom line is the users
will use stateful and stateless and we need a way to permit that and
also inform implementors
On Fri, Aug 13, 2004 at 02:28:46PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
[...]
Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean
that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
available but Information Request is not? Perhaps this is
On Thu, Aug 12, 2004 at 09:26:02AM -0400, Ralph Droms wrote:
Seems to me it would be useful to allow both M and O flag on.
While, in theory, the support for the subset of DHCPv6 indicated
by the O bit is implied by the support for all of DHCPv6
indicated by the M bit, it seems there would be
On Mon, Jun 14, 2004 at 04:05:04PM +0900, Jun-ichiro itojun Hagino wrote:
Hello IPv6:
In RFC 3493 it is said AF_INET6 sockets receive connections from IPv4 nodes,
mapping their addresses to :::IPv4 address. I think this behaviour is
on by default. Although it is not explicitly
On Thu, Mar 11, 2004 at 11:53:05PM -0500, Suresh Krishnan wrote:
On Thu, 11 Mar 2004 [EMAIL PROTECTED] wrote:
Now, who can tell if multicast echo request is the primary
multicast debugging mechanism or not ??
Since there is no alternate mechanism, this has become the primary and
On Thu, Mar 11, 2004 at 08:24:23AM +0200, Jari Arkko wrote:
[...]
This still leaves open what the behaviour for ICMPv6 Echo Request
should be. I would not bundle this issue with what the other
applications do, but my default answer would be to not respond
to multicast requests unless there is
On Tue, Nov 18, 2003 at 11:27:19AM +, Tim Chown wrote:
Good point, section 6.2 would need massaging on the next update of this spec.
I'll run a check against other documents.
I don't think RFC 3493 is a problem. I had a quick look, and all I can
find is that if getnameinfo() is passed a
On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote:
- there are really misbehaving DNS servers out there, which jeopardize
your IPv4 service if you query for 's, and
- if you have no IPv6 address, you'll waste a roundtrip or two in
queries
- maybe other considerations
On Tue, Oct 21, 2003 at 07:49:04AM -0700, Michel Py wrote:
Tim Chown wrote:
But if I want a VoIP communication from me (behind a NAT) to
some user behind a NAT, not using a 3rd party location server,
how does v4 deliver, without the receiving user having the pain
of port forwarding
70 matches
Mail list logo
