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
>>> r
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
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 pla
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 w
; 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
>>
>
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
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 b
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
At Wed, 26 Mar 2008 07:49:42 +0200 (EET),
Pekka Savola <[EMAIL PROTECTED]> 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
> > that, though). When a link-local address is the only available
> >
MEI Tatuya /
Cc: 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 ca
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
> that, though). When a link-local address is the only available
> address for host, there should normally be
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
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 s
Gabi Nakibly wrote:
> I certainly agree that the benefit of the simplicity of this rule is
> very desirable. However, this rule may be too restrictive. I am worried
> that there might be cases where it is desirable to send a packet to a
> (on-link) global address using a link-local address or UL
t;
To: Gabi Nakibly <[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
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
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
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 s
Pekka,
I agree that the scenario that was presented in
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03
is very problematic. However, I do not think that the root of the problem is
the destination address selection rule 2. As you mentioned, the
source-destination pair v6:{link-local,
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 predictions
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
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
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 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
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:
> http://tools.ietf.org/html/draft-ietf-v6o
+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 publis
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
27 matches
Mail list logo
