Hi Sheng, Ray,
On May 31, 2013, at 3:46 AM, Ray Hunter v6...@globis.net wrote:
[--snip--]
But why are people coming up with these schemes for encoding semantics
in the address prefixes in the first place? That's what I'd like to
understand first and foremost: what lack of functionality is
Ammar,
Instead of adding GeoLoc information in an IPv6 Extension Header, you may wish
to take a look at past current attempts to *potentially* encode such
information in the DNS. The most recent proposal to do so is the following:
http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03
Fred, Ran,
On Jan 4, 2012, at 4:11 PM, Templin, Fred L wrote:
Hi Ran,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of RJ Atkinson
Sent: Wednesday, January 04, 2012 2:44 PM
To: ipv6@ietf.org
Subject: Re: Fragmentation-related security
On Nov 10, 2011, at 12:53 PM, Brian E Carpenter wrote:
I support this change.
+1.
-shane
Regards
Brian Carpenter
On 2011-11-11 06:00, Bob Hinden wrote:
This email starts a one week 6MAN Working Group last call for adding text
and a reference to RFC6437 IPv6 Flow Label
On Nov 3, 2011, at 12:00 PM, Thomas Narten wrote:
John,
This should not be a surprising or controversial change to the
node-requirements document. The WG made the decision earlier that we'd
leave out a reference to the Flow Label work because we didn't want to
have node-requirements block
Brian,
On Jun 25, 2011, at 7:06 PM, Brian E Carpenter wrote:
Hi,
The discussion Jari's issue has died down, so I'd like to propose some
revised text:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
Fernando, Thomas,
On Apr 6, 2011, at 12:22 MDT, Fernando Gont wrote:
Thomas,
On 05/04/2011 05:36 p.m., Thomas Narten wrote:
Case in point about how we are being *extremely* loose in using the
term pseudo random.
[]
Part of my objection to the term pseudo random is that the term has
Thomas,
With respect to your comments on, both at the mic at the 6MAN WG and on the
list:
draft-ietf-6man-flow-3697bis-02
draft-ietf-6man-flow-ecmp-01
draft-ietf-6man-flow-update-04
You seem to take issue with a recommendation for creating/selecting a
flow-label that is pseudo-random. Can you
Thomas,
On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote:
[--snip--]
I take it as a given that doing ECMP on the src/dst address gets you
80% of what you need today. Adding in the Flow Label (if set) will
take you much further. I am not convinced you need real pseudo
randomness in the Flow
Chris,
I think we may want to be a little careful here. At a minimum, maybe take a
deep breath and think about this some, before making a final decision. :-)
See below.
On Feb 3, 2011, at 20:17 MST, Christopher Morrow wrote:
On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
[--snip--]
The second case concerns a number of paths across which traffic is to
be split. An attacker might want to overload a particular path. One
way to do this is to guess the Flow Labels being used for ECMP. But it
seems like
Lucy, Brian,
On Jan 11, 2011, at 08:41 MST, Yong Lucy wrote:
In fact no solution works well for short flows and the problem isn't
important
for long flows with few packets. So I think it's OK to discuss a solution
that works for long flows with many packets, since that covers most
of the
Fred,
On Jan 11, 2011, at 10:29 MST, Fred Baker wrote:
On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
It's probably better to say that a hash algorithm works well where
individual, long-lived flows (regardless of traffic type) are a small-ish
fraction of the physical BW of any
Hi Thomas,
Token operator here ... :-) See below.
On Jan 11, 2011, at 06:41 MST, Thomas Narten wrote:
Sorry to get back to basics, but I have not followed all the Flow
Label discussions or read all the drafts. I have read
draft-ietf-6man-flow-ecmp-00.txt
Thomas, All,
On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
Given that we expect people to put flow labels into a
hash function of some kind, a 20-bit pseudo random number
seems like a better default than 1,2,3,... (depending on
the
Hi Fernando,
Thanks for responding. See below.
On Nov 17, 2010, at 06:42 MST, Fernando Gont wrote:
Ok. Here's the text that I've included right bellow the formular:
cut here
This scheme should be used when a new flow is to be created (e.g., when
a new TCP connection is to be
Fernando,
On 11/9/2010 12:55 AM, Fernando Gont wrote:
The text you quoted says [counter] is initialized to some arbitrary
value, and is incremented once for each flow label value that is
selected.. That means that right after a Flow Label is selected
for each of your dozen flows, counter will
Hi Fernando,
On 11/9/2010 1:45 AM, Fernando Gont wrote:
And, it means that I can't just use the 3-tuple of
{src_ip, dst_ip, flow_label} as input-keys for LAG/ECMP. Specifically,
at time t1 if I have two flows that start up between the same 2-tuple:
1) FTP: 9 Gbps
2) WWW: 9 Gbps
... both of
Hi Fernando,
On 11/9/2010 3:05 AM, Fernando Gont wrote:
... the way I read the above, when it runs it /will/ return a unique
3-tuple of {src_ip, dst_ip, flow_label}. However, it's /not/ clear
*when* an implementation MUST execute the above pseudocode.
... when you need to select a new FL.
Hi,
At the mic at 6man today, I brought up a concern wrt this draft.
Specifically, the way I currently read this version of the draft, if
there are several [dozen] flows between the _same_ {source_IP,
destination_IP} 2-tuple, it appears they will end up with _same_
flow-label value.
As I
I support this draft's adoption as a WG draft.
-shane
On Oct 9, 2010, at 10:39 MDT, Brian Haberman wrote:
All,
I am starting a one week consensus call on adopting:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename :
Mikael,
On Sep 8, 2010, at 23:49 MDT, Mikael Abrahamsson wrote:
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
If we do agree on this, it's very helpful, because it guides all further
decisions. For example, it allows us to see that the label is immutable on a
best effort basis, rather than
Tim,
On Sep 9, 2010, at 05:05 MDT, Tim Chown wrote:
On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote:
In real life, ISPs consider DSCP as one thing they have the right to change
(along with TTL) in transit. I can imagine the flow label being considered
the same thing regardless of what
Hi Fernando,
Apologies for the delay.
On Sep 8, 2010, at 16:29 MDT, Fernando Gont wrote:
Hi, Shane,
I respectfully disagree that the hash provides the randomness
suitable for a flow-label to be used as an input-key for flow-based
load-balancing. In your draft, you've defined the
Brian, Steve,
On Sep 8, 2010, at 08:40 MDT, Steven Blake wrote:
On Wed, 08 Sep 2010 13:18:41 +1200, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Hi,
The authors of draft-carpenter-6man-flow-update (now also
including Shane Amante) are working on a new version. One
fundamental
Steve,
On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote:
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing
Hi Fernando,
On Sep 8, 2010, at 12:18 MDT, Fernando Gont wrote:
Hi, Shane,
With that said, I don't think this algorithm is necessarily ideal.
The FL value for any two flows from a src_addr, dst_addr pair may
only vary by a few bits, so if a switch/router uses a poor hash
algorithm for
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing that a flow-label be
constructed using the IPv6 Source Destination values as input-keys to a hash
function as follows:
Flow Label = counter
Wes,
On Aug 17, 2010, at 09:53 MDT, George, Wes E [NTK] wrote:
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Shane
Amante
Sent: Tuesday, August 03, 2010 1:20 PM
Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable
Because
Henmant,
On Aug 13, 2010, at 09:33 MDT, Hemant Singh (shemant) wrote:
-Original Message-
From: Randy Bush [mailto:ra...@psg.com]
Sent: Friday, August 13, 2010 10:50 AM
To: Hemant Singh (shemant)
Cc: Alain Durand; Pekka Savola; john.lough...@nokia.com;
nar...@us.ibm.com;
I support this becoming a WG doc.
-shane
On Jul 27, 2010, at 19:14 GMT+02:00, Brian Haberman wrote:
All,
As noted in today's session of 6MAN, the chairs are soliciting
input on adopting:
Title : Things To Be Considered for RFC 3484 Revision
Author(s) : A. Matsumoto, et
Lucy,
On Jul 28, 2010, at 13:58 GMT+02:00, Yong Lucy wrote:
What is flow label usage?
IMO: it enforces that a set of packets with the same flow label has to be
carried through the networks in the same path or belong to the same
application at host. Is that correct?
That appears to be a
Thomas, Christian,
I'm responding to both of you in a single message, since you both expressed
concern with choice 2, (locally-defined use of flow-labels), particularly in
the face of IPSec.
Let's first look at the situation as it stands today. Today, if hosts or IPSec
GW's sent IPSec ESP
Brian E Carpenter wrote:
Hi,
This is revised again according to discussion on the list, and some
off-list discussion with Shane Amante in particular.
Firstly, since there seemed to be a feeling that a full update
of RFC 3697 is better than publishing a set of changes, this is
now just
On Apr 26, 2010, at 06:17 MDT, Brian Haberman wrote:
All,
The 6MAN chairs would like feedback from the working group on adopting
draft-krishnan-ipv6-exthdr as a WG item. Please send your comments/opinions
to the mailing list (or the chairs) by May 7, 2010.
I support this draft being
Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
discussions, while maintaining the proposed duality
(RFC
for, say, calculating
a load-balancing hash for LAG and ECMP paths. See below for more.
On Apr 22, 2010, at 10:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 17:31, Shane Amante a écrit :
Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 04:56, Brian E
Hi Mark,
On Apr 15, 2010, at 04:36 MDT, Mark Smith wrote:
Hi Brian, Shane,
On Thu, 15 Apr 2010 15:52:15 +1200
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Regards
Brian Carpenter
On 2010-04-15 14:10, Shane Amante wrote:
Brian, Mark,
Brian: FWIW, I like
Bert,
On Apr 15, 2010, at 11:12 MDT, Manfredi, Albert E wrote:
I meant,
In Brian's I-D 02, an edge router at the destination side would *NOT* be
able to tell whether the flow label had been set by a source host or an
intervening router.
Bert
-Original Message-
From:
Brian, Mark,
Brian: FWIW, I like the direction of this version of draft much better than
previous versions; however, I agree with Remi that the current version is a bit
confusing at the moment and could likely be rewritten to be more simple and
just obsolete RFC 3967. In addition, I'm still a
other (future) use of the
flow-label. Thoughts?
-shane
On Apr 14, 2010, at 22:53 MDT, Brian E Carpenter wrote:
Shane Amante and I have updated this draft, and we'd like
the 6man WG to consider it as a potential BCP (or
alternatively, suggest another WG for it, but it does seem
like IPv6
Mark,
On Jan 27, 2010, at 00:44 MST, Mark Smith wrote:
Hi,
There have been a few discussions on a few operational mailing lists in
the last few weeks about the use of longer than /64s on point-to-point
links.
One valid reason to do so is to mitigate a Neighbor Discovery DoS,
initiated
Support.
-shane
On Oct 26, 2009, at 15:52 MDT, Brian E Carpenter wrote:
I fully support this draft.
Regards
Brian Carpenter
On 2009-10-23 07:00, Bob Hinden wrote:
All,
This message starts a 2-week 6MAN Working Group Last Call on
advancing:
Title : A Recommendation for
Francis,
On Aug 7, 2009, at 09:24 MDT, Francis Dupont wrote:
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest
Hi Margaret,
Apologies for the delay, but it took some time to follow-up with some
vendors. See below.
On Aug 5, 2009, at 12:33 MDT, Margaret Wasserman wrote:
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
On Aug 7, 2009, at 12:21 MDT, Iljitsch van Beijnum wrote:
Shane, thanks for infusing this discussion with some data.
On 7 aug 2009, at 20:05, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums
Brian,
On Aug 5, 2009, at 22:19 MDT, Brian E Carpenter wrote:
On 2009-08-06 05:34, Christopher Morrow wrote:
...
2) Removing other gems (or clarifying them) like the second
sentence in
the following:
---cut here---
IPv6 nodes MUST NOT assume any mathematical or other properties of
the
Margaret,
On Aug 5, 2009, at 08:12 MDT, Margaret Wasserman wrote:
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
Shane == Shane Amante sh...@castlepoint.net writes:
Shane Take a look at the following URL:
Shane http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane (Note, I can't vouch for the accuracy of the entire list,
Shane
Iljitsch,
On Aug 4, 2009, at 05:24 MDT, Iljitsch van Beijnum wrote:
On 30 jul 2009, at 18:49, Margaret Wasserman wrote:
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming that non-LISP stacks
will simply throw away these packets,
50 matches
Mail list logo
