Robert Elz wrote:
But, I am only concerned with the v6 case - the decision to use a v6
address is assumed to have already been made.
Unfortunately, this is not the way it works with default address selection.
the src node is looking at the complete set of potential v4 & v6 src &
dst addresses
t
Date:Wed, 11 Jun 2003 09:07:14 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Then please explain us how do you do it, I'd be very happy to learn,
| especially in the case where some port on the destination host
| support v4 & v6 an
On Wednesday, June 11, 2003, at 01:08 AM, Robert Elz wrote:
Date:Tue, 10 Jun 2003 10:47:53 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Reachability os one thing, but you may have to wait for TCP
timeouts.
| RFC1122, section 4.2.3
Date:Wed, 11 Jun 2003 08:15:10 -0700
From:"Michel Py" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The problem is that the only way to _really_ test reachability is to
| actually try.
Of course - but what we're looking for here is a hint as to which addre
kre,
| Alain Durand wrote:
| Reachability os one thing, but you may have to wait for TCP timeouts.
| RFC1122, section 4.2.3.5 TCP Connection Failures
| Says that the initial SYN has to wait at least 3 minutes...
> kre wrote:
> You're assuming that I am actually using a TCP SYN to
> detect reachab
Date:Tue, 10 Jun 2003 10:47:53 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Reachability os one thing, but you may have to wait for TCP timeouts.
| RFC1122, section 4.2.3.5 TCP Connection Failures
| Says that the initial SYN has
Robert Elz wrote:
I do "local first" (actually a variation of that, but the effects for this
purpose are the same) - the implementation waits up to about 100ms for
a response. If it gets an answer, it goes on with the local address. If
it gets an ICMP it switches to global, if the 100ms passes w
Date:Mon, 09 Jun 2003 11:16:04 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| >Agreed. There could be a long timeout on connection if we use an invalid
| >address (local or global) as our first choice, and an out-of-scope local is
Andrew White wrote:
Pekka Savola wrote:
That's not the complete picture. Addresses leak. They leak to others
using the local scope, but without connectivity. I'd much prefer using
globals first, because falling back to globals from first trying locals
could take a long time (consider e.g.
Date:Fri, 6 Jun 2003 15:51:14 +0100
From:Derek Fawcus <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Doing this would constitute a _redifinition_ of the current
| SL behaviour,
No, it doesn't. SL, as currently defined, allows for any random bits
in the "up
Date:Fri, 6 Jun 2003 09:28:54 +0100
From:Zefram <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| but it's quite different from the suggestion
| that we started with, which was to have persistent unique prefixes in
| globally-scoped address space.
That may h
Christian,
Isn't that cool? We had this discussion before. In the spring of 1997,
as a matter of fact. And the suggestion then was:
> Date: Tue, 13 May 1997 11:25:42 -0400
> From: [EMAIL PROTECTED] (Christian Huitema)
> Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for
In hindsi
On Thu, Jun 05, 2003 at 12:56:15AM +0100, Ole Troan wrote:
> I agree with kre, stick to fec0::/10.
I disagree. Doing this would constitute a _redifinition_ of the current
SL behaviour, not any form of deprecation.
If people are desperate to use a /10 range, there's always fe00:/10 and
fe40::/1
Zefram wrote:
>People have started to suggest attaching scoping semantics to fc00::/7
>adddresses, which is what led to fc00::/10. I think this was a mistake.
>Leave fc00::/7 without special semantics -- that's the point of it.
>People that want scoping: if you want fc00::/10, you know where to ge
On Wed, Jun 04, 2003 at 07:56:08PM -0700, Tim Hartrick wrote:
> > > For what it is worth, I agree with kre as well.
> >
> > Isn't that cool? We had this discussion before. In the spring of 1997,
> > as a matter of fact. And the suggestion then was:
> >
>
> I think of lots of things to call it, b
>I agree with kre, stick to fec0::/10.
So many people have spoken in favour of that that I think I need to
state the contrary position. Having uniquish IDs under fec0::/10 may
well be a useful technique, but it's quite different from the suggestion
that we started with, which was to have persiste
Date:Wed, 04 Jun 2003 15:51:31 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| My point is that I'd rather like the default case to be that apps that
| require global addresses don't have anything special to do to work.
As it happens
Date:Thu, 05 Jun 2003 10:55:50 +0200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| FEC0::/48 is reserved and not to be used. (This is a shot at backwards
| compatibility for existing usage.)
I'm not sure that we really need that. T
> Ole Troan wrote:
> I agree with kre, stick to fec0::/10.
Me too. A scheme with the lower part of it for random and the upper part
of it for a fee would work too. Although this would represent only 15
prefixes per person in the long run (that's only 4 million subnet for a
family of 4, way to smal
Robert Elz wrote:
>
> Date:Wed, 04 Jun 2003 07:29:05 -0700
> From:Bob Hinden <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | I think you are suggesting that the draft be changed to reuse the FEC0::/10
> | space with a resulting 38-bit global ID. This
Pekka Savola wrote:
>
> That's not the complete picture. Addresses leak. They leak to others
> using the local scope, but without connectivity. I'd much prefer using
> globals first, because falling back to globals from first trying locals
> could take a long time (consider e.g. stupid firewall
Pekka Savola wrote:
>
> On Wed, 4 Jun 2003, Alain Durand wrote:
> > 100% agreed. Still, we have to pick a default. My point is that I'd
> > rather like the default case to be that apps that require global
> > addresses don't have anything special to do to work.
>
> Agree here.
>
> Another altern
On Thu, 5 Jun 2003, Andrew White wrote:
> I prefer the behaviour specified by default address selection - pick the
> smallest 'scope' which matches unless the application has a good reason to
> do otherwise.
>
> Stability aside, the 'smallest matching scope' rule only fails for
> applications that
On Wed, 4 Jun 2003, Alain Durand wrote:
> 100% agreed. Still, we have to pick a default. My point is that I'd
> rather like the default case to be that apps that require global
> addresses don't have anything special to do to work.
Agree here.
Another alternative way to proceed might be to leave
Alain Durand wrote:
>
> 100% agreed. Still, we have to pick a default.
> My point is that I'd rather like the default case to be that apps that
> require global addresses don't have anything special to do to work.
I prefer the behaviour specified by default address selection - pick the
smallest '
> Bob,
>
> >
> >>Hence, I see no real reason at all to stray from FEC0::/10 - and
lots
> >>of reasons to remain in that space.
> >
> > I think you are suggesting that the draft be changed to reuse the
> > FEC0::/10 space with a resulting 38-bit global ID. This would allow
> > for 274,877,906,944
Bob,
>
>>Hence, I see no real reason at all to stray from FEC0::/10 - and lots
>>of reasons to remain in that space.
>
> I think you are suggesting that the draft be changed to reuse the
> FEC0::/10 space with a resulting 38-bit global ID. This would allow
> for 274,877,906,944 prefixes, or 30
>>Hence, I see no real reason at all to stray from FEC0::/10 - and lots
>>of reasons to remain in that space.
>
> I think you are suggesting that the draft be changed to reuse the
> FEC0::/10 space with a resulting 38-bit global ID. This would allow
> for 274,877,906,944 prefixes, or 30 per person
Robert Elz wrote:
What's more, there are cases where both will work. For those, which
order we select as the default determines which of the two is used.
I agree.
For
this case (which is for me actually the interesting case - if only
one address works, that's the one that will end up being us
Date:Wed, 04 Jun 2003 07:29:05 -0700
From:Bob Hinden <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think you are suggesting that the draft be changed to reuse the FEC0::/10
| space with a resulting 38-bit global ID. This would allow for
| 274,877,906
KRE,
Hence, I see no real reason at all to stray from FEC0::/10 - and lots
of reasons to remain in that space.
I think you are suggesting that the draft be changed to reuse the FEC0::/10
space with a resulting 38-bit global ID. This would allow for
274,877,906,944 prefixes, or 30 per person in
Date:Tue, 03 Jun 2003 17:16:52 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I will argue that prefering global scope (when available) will
| _generally_ result in having better chance of connecting.
| Yes, I agree with you, there
Date:Tue, 03 Jun 2003 17:16:52 -0700
From:Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| On another note, we have shipping IPv6 products.
| I think is is getting very late in the game to
| invent yet another address format that nodes
| are s
Christian,
> >
> > For what it is worth, I agree with kre as well.
>
> Isn't that cool? We had this discussion before. In the spring of 1997,
> as a matter of fact. And the suggestion then was:
>
I think of lots of things to call it, but "cool" is not one of them.
tim
Fred Templin wrote:
Pekka Savola wrote:
On Tue, 3 Jun 2003, Robert Elz wrote:
There are also those who will always prefer to use local addresses over
global, regardless of what is available. I'd have global addresses
available everywhere, and use them only when that's the only thing that
w
Pekka Savola wrote:
On Tue, 3 Jun 2003, Robert Elz wrote:
There are also those who will always prefer to use local addresses over
global, regardless of what is available. I'd have global addresses
available everywhere, and use them only when that's the only thing that
works (when routing cann
>> Andrew White wrote:
>> - A network with access to the global internet via
>> more than one independent path.
> Pekka Savola wrote:
> In some cases, it's more detailed than that, but yes.
Agree.
>> Andrew White wrote:
>> - A node with more than one usable address (having addresses
>> in more
Date:Tue, 3 Jun 2003 14:28:14 +0300 (EEST)
From:Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Hence why the ordering could be reversed: no modifications necessary for
| working-by-default-for-the-first-try configuration.
Which is "working-by-
On Tue, 3 Jun 2003, Robert Elz wrote:
> | Yes, applications should of course be *able* to influence these, if they
> | desire so, provided that:
> | - they don't need to if they don't want to (including multi-party apps)
>
> I doubt that the latter (parenthetical requirement) is possible.
Date:Tue, 3 Jun 2003 10:29:14 +0300 (EEST)
From:Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Yes, applications should of course be *able* to influence these, if they
| desire so, provided that:
| - they don't need to if they don't want to
Pekka Savola wrote:
>
> I hope you're not implying that apps should know the difference between
> the two? That would be broken. The host probably could, though.
In most situations, an application would not be required to know the
difference between the addresses, relying on correct behaviour o
On Mon, 2 Jun 2003, Bob Hinden wrote:
> 4) The scope of these address is smaller from global unicast address but
> larger than site-local. They are scoped in a different manner than
> link-local, site-local, and global in that the scope of an individual /48
> prefix is created by a set of adhoc
On Tue, 3 Jun 2003, Andrew White wrote:
> > I hope you're not implying that apps should know the difference between
> > the two? That would be broken. The host probably could, though.
>
> In most situations, an application would not be required to know the
> difference between the addresses, rel
43 matches
Mail list logo
