Fred,
I think I am in general agreement of the consequences, but it isn't
about scope, it is about reachability. Anytime there is a a choice
of
addresses to use, the same issue come to play. It's hard to know
about
reachability with out prior knowledge or trying it out and seeing
On Mar 31, 2008, at 10:10 AM, Bob Hinden wrote:
Fred,
I think I am in general agreement of the consequences, but it isn't
about scope, it is about reachability. Anytime there is a a
choice of
addresses to use, the same issue come to play. It's hard to know
about
reachability with
On 2008-03-29 16:01, Fred Baker wrote:
On Mar 28, 2008, at 12:51 PM, Hemant Singh (shemant) wrote:
I think I am in general agreement of the consequences, but it isn't
about scope, it is about reachability. Anytime there is a a choice of
addresses to use, the same issue come to play. It's
On Thu, 27 Mar 2008, JINMEI Tatuya / wrote:
The scenario where a router advertises the default route yet does not
advertise any prefix information (or prefix information does not set
the autoconfig bit) is still a valid scenario (e.g., I could imagine
DHCPv6-only deployments using this;
On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
- use a ULA source address if and only if the destination is a ULA
in the same prefix
I think that is broken. There's a reason ULAs are defined as global
addresses.
but they are *not* global addresses. If they were, they would be
Fred,
On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
- use a ULA source address if and only if the destination is a ULA
in the same prefix
I think that is broken. There's a reason ULAs are defined as global
addresses.
but they are *not* global addresses. If they were, they would
; Brian E Carpenter;
Pekka Savola
Subject: Re: RFC3484 destination address selection rule 2 is buggy
Fred,
On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
- use a ULA source address if and only if the destination is a ULA
in the same prefix
I think that is broken. There's a reason ULAs
On Mar 28, 2008, at 12:51 PM, Hemant Singh (shemant) wrote:
I think I am in general agreement of the consequences, but it isn't
about scope, it is about reachability. Anytime there is a a choice of
addresses to use, the same issue come to play. It's hard to know
about
reachability with
: Iljitsch van Beijnum; ipv6@ietf.org
Subject: Re: RFC3484 destination address selection rule 2 is buggy
On Tue, 25 Mar 2008, JINMEI Tatuya / wrote:
v4:{site-local,global} is special and is not that harmful as long as
the network is properly configured (I know we cannot always assume
At Fri, 14 Mar 2008 00:27:26 +0200 (EET),
Pekka Savola [EMAIL PROTECTED] wrote:
While the default router persistence is an interesting observation, the
more
interesting one is why the default address selection algorithm pick
source,destination pair of v6:{link-local,global} which is almost
Fred,
On 2008-03-19 01:33, Fred Baker wrote:
On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:
...
Similarly, there is no sense using a ULA source address unless the
destination is in the same ULA. If the destination is a global
address it might or might not be able to reply, but the
it will be avoided by destination
address selection rule 1.
Gabi
- Original Message
From: Pekka Savola [EMAIL PROTECTED]
To: ipv6@ietf.org
Cc: Iljitsch van Beijnum [EMAIL PROTECTED]
Sent: Friday, March 14, 2008 12:27:26 AM
Subject: RFC3484 destination address selection rule 2 is buggy
FYI
Pekka Savola wrote:
Maybe the critical thing that has been missing in the RFC3484
discussions has been have vendors already fixed this? how? which
approach has worked and which not?
When we were working on
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03, I
prototyped the
On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:
Determining whether the destination address is in the zone of a
source address can be tricky. However, it is fairly easy in the
common case where the source address is link-local and the
destination address is global. If the latter is
Fred Baker wrote:
Speaking for myself, there is a simpler rule in that special case
that imght be instructive in the ULA case.
There is no sense in using a link-local address as a source address
unless one is sending to someone on the same LAN. Hence, there is no
sense in suing a
[EMAIL PROTECTED]
Cc: Pekka Savola [EMAIL PROTECTED]; ipv6@ietf.org; Iljitsch van Beijnum
[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2008 2:33:15 PM
Subject: Re: RFC3484 destination address selection rule 2 is buggy
On Mar 18, 2008, at 5:10 AM, Gabi Nakibly wrote:
Determining whether
Le Friday 14 March 2008 00:44:11 Francis Dupont, vous avez écrit :
Perhaps some of us didn't remember but:
- I predicted the RFC 3484 will be always at least a phase back from
what we want.
- I predicted too it would take a not reasonable amount of time to
get the document published or
FYI,
While the default router persistence is an interesting observation, the more
interesting one is why the default address selection algorithm pick
source,destination pair of v6:{link-local,global} which is almost certain not
to work instead of v4:{site-local,global}
(ietf-464nat is using
Perhaps some of us didn't remember but:
- I predicted the RFC 3484 will be always at least a phase back from
what we want.
- I predicted too it would take a not reasonable amount of time to
get the document published or updated.
Unfortunately both predictions were right so again I propose to
+1
On 3/13/08 6:44 PM, Francis Dupont [EMAIL PROTECTED] wrote:
Perhaps some of us didn't remember but:
- I predicted the RFC 3484 will be always at least a phase back from
what we want.
- I predicted too it would take a not reasonable amount of time to
get the document published or
Le Friday 14 March 2008 00:27:26 Pekka Savola, vous avez écrit :
This issue was first reported about 5 years ago by Alain Durand et al and
yet there is no fix yet (and no mention in the default address selection
problem statement), see section 2 of:
On Thu, 13 Mar 2008, Francis Dupont wrote:
Perhaps some of us didn't remember but:
- I predicted the RFC 3484 will be always at least a phase back from
what we want.
- I predicted too it would take a not reasonable amount of time to
get the document published or updated.
Unfortunately both
In your previous mail you wrote:
Francis, I don't think BCP status would change this; that's still a
= I disagree: the procedure for BCPs is lighter and BTW there is nothing
when you look at it which justifies a standard track (we should not
promote it to a draft standard for instance :-).
On Fri, 14 Mar 2008, Rémi Denis-Courmont wrote:
Le Friday 14 March 2008 00:27:26 Pekka Savola, vous avez écrit :
This issue was first reported about 5 years ago by Alain Durand et al and
yet there is no fix yet (and no mention in the default address selection
problem statement), see section
24 matches
Mail list logo
