Le 21 avr. 2010 à 23:17, Brian E Carpenter a écrit :
On 2010-04-21 20:50, Rémi Després wrote:
Hi Brian,
I wonder what you think of what I answered to James on another discussion
thread.
I agree. I think that particular SHOULD in the RFC is an error. It SHOULD
have said something like:
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 3697-like
use still possible, but locally-defined use also possible
Announcing the USGv6 Testing Meeting at NIST.
To be held on Thursday May 20th 2010 in the AML Conference Room,
Building 215 Room C103, from 9am till 5pm.
Following publication of the USG Profile NIST has established a testing
program to determine products' compliance to USGv6 capabilities.
Thanks Sheila! Good to see you working on IPv6 so vigorously recalling our
days of work on IPsec back in 99.
I have Copied the North American v6 Task Force members and the IPv6 Ready
logo program team.
Cheers
Latif
-Original Message-
From: ipv6-boun...@ietf.org
Hi,
I don't understand a specific point in DAD procedure specified in RFC
4862. In section 5.4.3, it is said:
5.4.3. Receiving Neighbor Solicitation Messages
[snip]
If the source address of the Neighbor Solicitation is the unspecified
address, the solicitation is from a node performing
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
Terry,
You touch a core issue of the he IPv6 Ready Logo program.
The v6RL Phase II (Logo) includes IPsec interop testing.
Though we have stayed away at this staged from mandating IPsec per RFC to
give industry the time to put its arms around IPv6 issues first,
there a dozen of
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 Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
The IESG has approved the following document:
- 'A Recommendation for IPv6 Address Text Representation '
draft-ietf-6man-text-addr-representation-07.txt as a Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Jari Arkko and
Pete,
This meeting is very crucial especially for vendors and to a certain extent to
ISPs, so John could publish this event (most probably already done so) to his
ARIN constituency as it’s Sheila’s desire to get a good representation from all
stakeholders.
It would be good to time
On Thu, 22 Apr 2010 10:08:34 +0200, Rémi Després remi.desp...@free.fr
wrote:
Le 21 avr. 2010 à 23:17, Brian E Carpenter a écrit :
On 2010-04-21 20:50, Rémi Després wrote:
Hi Brian,
I wonder what you think of what I answered to James on another
discussion thread.
I agree. I think that
At Thu, 22 Apr 2010 17:22:26 +0200,
Jean-Michel Combes jeanmichel.com...@gmail.com wrote:
5.4.3. Receiving Neighbor Solicitation Messages
[snip]
If the source address of the Neighbor Solicitation is the unspecified
address, the solicitation is from a node performing Duplicate
Le 22 avr. 2010 à 19:31, Steven Blake a écrit :
On Thu, 22 Apr 2010 10:08:34 +0200, Rémi Després remi.desp...@free.fr
wrote:
Le 21 avr. 2010 à 23:17, Brian E Carpenter a écrit :
On 2010-04-21 20:50, Rémi Després wrote:
Hi Brian,
I wonder what you think of what I answered to James on
Remi,
I think we may be in agreement that domain-specific uses of the flow-label are
problematic for the reason you illustrate below? Namely, that once one domain
sets it to something that is not known to be a 3- or 5-tuple of the IPv6
header, then you lose the ability to use that flow-label
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Shane Amante
c) Declare the flow-label is _immutable_ and must be set by
all hosts and must only contain a 3- or 5-tuple hash of the
appropriate IPv6 headers. Further use cases for the
At Wed, 14 Apr 2010 07:58:05 -0400,
Simon Perreault simon.perrea...@viagenie.ca 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
On 2010-04-23 06:40, Rémi Després wrote:
Le 22 avr. 2010 à 19:31, Steven Blake a écrit :
On Thu, 22 Apr 2010 10:08:34 +0200, Rémi Després remi.desp...@free.fr
wrote:
Le 21 avr. 2010 à 23:17, Brian E Carpenter a écrit :
On 2010-04-21 20:50, Rémi Després wrote:
Hi Brian,
I wonder what
Hi Brian,
Well, unintended may be taken as permitting the hash (its intent of the
hash that two different 5-tuples give in general two different values, with
only statistically rare exceptions), but better words may also be proposed.
In any case, explicitly permitting the 5-tuple hash is
(Sorry, I messed up the subject of this thread by including DRAFT)
On 2010-04-23 07:30, Shane Amante wrote:
snip
I completely agree that this is a challenging problem;
however, I see a few ways of potentially dealing with it:
a)
Restoral of domain-specific flow-label values, (your
Sheila
Like Latif said, THANK YOU!
As you know from the Seattle meeting with aviation industry representatives and
the vendor community last fall, the Internet security protocols'
interoperability is a key lynchpin in being able to ensure that the next
generation of Internet enabled aircraft
personally, I would prefer to see it *mutable*, and undefined. Given that there
are many host implementations out there, I could imagine difficulties getting
any specific specification (such as a hash) widely deployed in a finite amount
of time. However, if a network could use it to identify an
On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote:
However, consider that the flow label is a forgeable field, not
protected by any checksum (including IPSEC).
So maybe mutability is in fact the only way to make it safe to
use across domain boundaries?
Interesting. I had it in my head
The problem for me is that if it is arbitrarily mutable, then we can not
use the flow label in a reliable and useful fashion in the ECMP / LAG.
After all, if it is arbitrarily mutable some ISP might set it to 0xFACE
because that was useful to them without regard to specific flows.
I would
It is already mutable, as it turns out. It always was.
On Apr 22, 2010, at 6:57 PM, Joel M. Halpern wrote:
The problem for me is that if it is arbitrarily mutable, then we can not use
the flow label in a reliable and useful fashion in the ECMP / LAG. After all,
if it is arbitrarily mutable
24 matches
Mail list logo
