Hi,
In IPv6 stack implementation,
How IPv6 stack should select the outgoing interface to choose (when multiple
interfaces) are available? Typically when the destination is the link-local
address which may be on-link on both the interfaces (before the neighbor
discovery) is done?
Should IPv6
On Wed, 14 Apr 2010 02:00:36 -0700 (PDT), Parav Pandit
paravpan...@yahoo.com wrote:
How IPv6 stack should select the outgoing interface to choose (when
multiple interfaces) are available? Typically when the destination is the
link-local address which may be on-link on both the interfaces
Thanks for the quick help.
Good example of UDP.
So in case of TCP, client which tries to connect to the server, should provide
its link-local source address during socket(), bind() calls. Based on that IPv6
stack will figure out the out-going interface.
Is that correct understanding?
Regards,
On 2010-04-14 06:56, Parav Pandit wrote:
So in case of TCP, client which tries to connect to the server, should
provide its link-local source address during socket(), bind() calls.
No. On the client side there should be no bind() call, and the socket()
call is unaffected since it doesn't take
Brian, Sheng,
I carefully read the draft, and read again RFC 3697 and
draft-carpenter-6man-flow-update-02.
The draft is IMHO overly hard to understand but, unless I misunderstand its
intent (which is quite possible), I appreciate what it proposes.
I do support the intent, but feel uncomfortable
Hi, I came across this draft coming from the ROLL space where a proposal
exists to use the Flow Label changed enroute maybe.
Besides the fact that I find ROLL use of such spec of 6MAN not being
ready, i.e. in its infance (I will suggest that to the ROLL WG), I have
a general comment here in
I take advantage of my slot here to also talk about the fact that I
believe Flow Labels and IPv6 Flows in general are little known in MEXT.
For example the MEXT WG defines an IPv6 flow to be a group of packets
matching a traffic selector, different than the rfc3697 idea of
3-tuple of the Flow
On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote:
Hi, I came across this draft coming from the ROLL space where a proposal
exists to use the Flow Label changed enroute maybe.
Alex,
I think you're misrepresenting ROLL here, even though (after your objections
there) the use of the flow
I think this topic belongs to the MIF WG. Maybe they have
already discussed it. If not, they probably should.
http://datatracker.ietf.org/wg/mif/charter/
Brian
On 2010-04-14 21:00, Parav Pandit wrote:
Hi,
In IPv6 stack implementation,
How IPv6 stack should select the outgoing
For whom is this Flow Label update intended?
1. For all the people who have proposed use cases that are incompatible
with RFC 3697. This is briefly discussed in the draft, and I plan
another draft with more details about that.
2. To unlock the uses cases already proposed that are compatible
Alexandru,
I find this proposal to change the Flow Label behaviour to come in too
early, at a point where we don't yet have widespread use of simple Flow
Labels (or is it widely used?).
But that's the problem. If you have read the -02 draft, you will understand
that flow label usage today is
Rémi,
Thanks for the analysis. Indeed, the conclusion may be, assuming
the WG is interested at all, that a complete refresh of RFC 3697
is better than publishing a delta.
I agree that it is a bit complicated to explain, although the
underlying concept is quite clear: allow local use of the
flow
Hi Brian and Sheng,
On Wed, 14 Apr 2010 16:48:25 +1200
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Hi,
This is completely revised from the proposal we presented
in Anaheim. This version allows locally defined use of
the flow label in a simpler way, as the discussion suggested.
Hi Mark,
On 2010-04-15 09:59, Mark Smith wrote:
Hi Brian and Sheng,
On Wed, 14 Apr 2010 16:48:25 +1200
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Hi,
This is completely revised from the proposal we presented
in Anaheim. This version allows locally defined use of
the flow
Hi,
Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source port, dest port, protocol #}.
This is relatively trivial at line speed in IPv4 since
these things are at fixed locations in the header. But in
Le 14/04/2010 22:23, Philip Levis a écrit :
On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote:
Hi, I came across this draft coming from the ROLL space where a
proposal exists to use the Flow Label changed enroute maybe.
Alex,
I think you're misrepresenting ROLL here, even though
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Brian E Carpenter
Sent: Wednesday, April 14, 2010 6:26 PM
To: 6man
Cc: Nevil Brownlee
Subject: Extracting the 5-tuple from IPv6 packets
Hi,
Common practice in network monitoring and in QoS
Hi Brian,
Or we can strongly recommend that all hosts set the flow label, so
that we can use the 3-tuple {source address, dest address, flow label}.
Using a 3-tuple helps in stateless firewalls/ middle boxes/ ECMP,
which cannot/ do-not reassemble all fragments. The 5-tuple is not
available for
[Senthil] In order to get to the port numbers you would still have to
traverse the extension headers and in the process you would identify the
protocol too, isnt that right?
Oh my yes! How embarassing, but it makes the problem even worse.
Regards
Brian Carpenter
On 2010-04-15 10:42,
Brian,
On Apr 14, 2010, at 3:26 PM, Brian E Carpenter wrote:
Hi,
Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source port, dest port, protocol #}.
This is relatively trivial at line speed in
Using RFC 3697 instead of Traffic Selectors (draft-ietf-mext-binary-ts) has
been discussed in MEXT, here is a pointer:
http://www.ietf.org/mail-archive/web/mext/current/msg03327.html
I don't think MEXT opted for that kind of use, they want more generic flow
description.
BR,
Behcet
-
On Apr 14, 2010, at 15:26, Brian E Carpenter wrote:
What do people think?
I think this topic reminds me of
http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr.
This document proposes a new family of IPv6 extension headers that
will be encoded in a consistent format so that it is
On Wed, Apr 14, 2010 at 7:03 PM, Vishwas Manral vishwas.i...@gmail.com wrote:
Hi Brian,
Or we can strongly recommend that all hosts set the flow label, so
that we can use the 3-tuple {source address, dest address, flow label}.
Using a 3-tuple helps in stateless firewalls/ middle boxes/ ECMP,
On Wed, Apr 14, 2010 at 7:16 PM, Bob Hinden bob.hin...@gmail.com wrote:
Brian,
On Apr 14, 2010, at 3:26 PM, Brian E Carpenter wrote:
Hi,
Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source
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
On Apr 14, 2010, at 3:32 PM, Alexandru Petrescu wrote:
Le 14/04/2010 22:23, Philip Levis a écrit :
On Apr 14, 2010, at 10:21 AM, Alexandru Petrescu wrote:
Hi, I came across this draft coming from the ROLL space where a
proposal exists to use the Flow Label changed enroute maybe.
Alex,
Regards
Brian Carpenter
On 2010-04-15 14:10, Shane Amante wrote:
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
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 maintenance).
We think this version responds to the discussion in Anaheim
and the comments we've received; the main
A question for the WG.
Underneath the diagram of the TEP's, there is reference to the fact that the
input keys to the modulo(N) hash are quite large, which could be problematic
for HW implementations. However, below that, in the last bullet in Section 2,
there is a statement about adding the
Hi,
As per RFC 2464, Link local address for Ethernet based interfaces are based on
the EUI-64 (derived from the MAC address).
I have #3 questions based on this.
In this case,
when one Ethernet based host(from its link-local source) tries to ping the
other Ethernet based host, it knows the
30 matches
Mail list logo
