Subject: Status of <draft-hinden-ipv6-global-local-addr-00.txt>

From: Bob Hinden <[email-masked]>
Date: Mon, 02 Jun 2003 16:03:31 -0700

[My opinions as document author]

Overall I believe there is general agreement that this type of address is 
an improvement over site-local because the prefixes are unique.

Below is my summary of conclusions reached and open issues raised on the 
mailing list.

1) A global-ID of 41 bits is a reasonable choice.

2) It is important to allow for /48 prefixes (with 16-bit subnet IDs) to 
maintain compatibility with RFC3177.

3) The central allocation proposed in the draft is OK for some situations, 
but there is also need for local allocation for sites who can not want to 
use a central allocation authority.  Pseudo-random numbers is a reasonable 
choice for this given the field size..  The suggestion made on the list to 
split FC00::/7 into FC00::/8 and FD00::/8 to allow for each type of 
allocations is a good approach.

I plan to make this change in the next version of the draft and include 
pseudo-code of an local allocation algorithm.  Brain Haberman is helping 
with this text.

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 routing agreements and is not limited 
by the non-uniqueness of the prefix like site-local.

 From a host's perspective this difference in scope shows up by different 
reachability than global unicast and could be handled by default that 
way.  It is probably better for nodes and applications to treat them 
differently from global unicast addresses.  A starting point might be to 
give them preference over global unicast, but fall back to global unicast 
if a particular destination is found to be unreachable.  Much of this 
behavior can be controlled by how they are allocated to nodes and put into 
the DNS.  However it is useful if a host can have both types of addresses 
and use them appropriately.  This creates a host with multiple global 
addresses, a form of multihoming.

Approaches to this problem have been proposed in drafts like 
<draft-de-launois-multi6-naros-00.txt> where a server is queried for the 
best source and destination address pair to reach a destination.  In the 
long term this approach might be combined with a DNS request where the 
request included all of the requesters source addresses that could be used 
and the resolver would return the preferred source and destination 
addresses.  This is, of course, not a trivial change to DNS but might be a 
reasonable approach to move forward in this area.

I would proposed that the IPv6 w.g. define the address format and default 
node and application behavior, and leave the more ambitious address 
selection solutions to multi6 or other working groups as appropriate.

I would appreciate your feedback and thoughts.

Thanks,
Bob

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Jun 2003 08:48:53 +0300 (EEST)

On Mon, 2 Jun 2003, Bob Hinden wrote:
> differently from global unicast addresses.  

I hope you're not implying that apps should know the difference between 
the two?  That would be broken.  The host probably could, though.

> A starting point might be to 
> the DNS. 

I think a better method would be to give preference to global unicast, 
ie., reverse the scoping rule to prefer the greatest scope.

The communication would still work if a node had only local unicast 
addresses though, or if global addresses were blocked in a firewall etc.

This is particularly important if local addresses like these are ever
getting into DNS or the like.

> However it is useful if a host can have both types of addresses 

I fail to see how a local and a global address could be considered a form 
of multihoming.
 
[snip]

> selection solutions to multi6 or other working groups as appropriate.

Yep.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Andrew White <[email-masked]>
Date: Tue, 03 Jun 2003 17:12:59 +1000

> 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 of
gethostbyname (destination address selection) and source address selection.

However, certain applications may wish to deliberately operate at a certain
scope (such as those doing ip address referrals between hosts which have
local and global addresses and those which only have global addresses) and
these would need to override the default address selection rules, thus being
conscious of address scoping.

> ie., reverse the scoping rule to prefer the greatest scope.

On what grounds?  Local scoped addresses are not mandatory, and thus should
only be put in place if they are intended to be used.  To my way of
thinking, the presence of a locally scoped address suggests that the network
is unwilling to trust the global address for local communication, and would
thus expect the local address to be preferred for local-local traffic.

> I fail to see how a local and a global address could be considered a form

It depends on your definition of multi-homing.  I've hear the term used in
the following ways:

- A network with access to the global internet via more than one independent
path.

- A node with more than one usable address (having addresses in more than
one logical subnet simultaneously).

The second definition is being referred to above.

-- 
Andrew White                [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Jun 2003 10:29:14 +0300 (EEST)

> conscious of address scoping.

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)
 - the API is de-facto standardized so every app doesn't have to reinvent 
the wheel for 10 different operating systems

> only be put in place if they are intended to be used.

Yes, but used by *WHOM* ?

If they're used in the site, and that only, typically that would be OK.

This also begs the question whether local-scoped addresses would be
deployed without global addresses or not (as some have required).  If
there are local-only nodes, the reason to deploy local-scoped addresses
could be simply to use them when needed, no more no less -- without 
disturbing the global communication of nodes with global addresses!

> To my way of
> is unwilling to trust the global address for local communication, 

The motivations vary a lot.

> and would

That may be a desire, yes, but they may be others -- particularly 
regarding how you intend to deploy the addresses.

To me, by default using the global addresses would seem like a plus: even
if/when they leak (to a site which is also using local addresses), nothing
bad happens: the global addresses are still tried first (and not second)
-- the way it should be.  This way, people could also publish local
addresses in the non-split DNS (whether that's a good or bad thing is a
different issue).

> - A network with access to the global internet via more than one independent

In some cases, it's more detailed than that, but yes.

> one logical subnet simultaneously).

This is an abuse of the term.
 
> The second definition is being referred to above.

That's "multi-addressing".  (Note that there's a significant overlap with 
the two definitions above.)

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Jun 2003 17:44:35 +0700

Date:        Tue, 3 Jun 2003 10:29:14 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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.

  |  - the API is de-facto standardized so every app doesn't have to reinvent 
  | the wheel for 10 different operating systems

That would indeed be nice.

  | This also begs the question whether local-scoped addresses would be
  | deployed without global addresses or not (as some have required).

Pekka, there's no way to stop it.   Regardless of what address forms
are created, or not created, this is going to happen, however dumb we
see it as being.   What we need to do is minimise the harm, we cannot
prevent it.

  | If there are local-only nodes, the reason to deploy local-scoped addresses
  | could be simply to use them when needed, no more no less -- without 
  | disturbing the global communication of nodes with global addresses!

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 cannot get other addresses to work).

None of us can impose our model of how any of this should work on the
world at large - we have to be able to cope with different methods of
building networks.   And yes, that means that applications either have
to be able to cope as well, or they need to simply admit that they're
not going to work (or not work well) in all environments.

  | That's "multi-addressing".  (Note that there's a significant overlap with 
  | the two definitions above.)

The difference doesn't matter here.   All that matters at this level is
that a node has two different addresses, which don't work the same from
all different possible peers - from some one works better, from others the
other does, to the extent sometimes that one of them won't work at all
(and that one can be either address, of any scope).

Bob, in the next version of your draft, could you include some mention of
how this change (from FEC0::/10 to FC00::/7) is planned to affect Node
Information Queries (from Matt Crawford's draft) ?

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 3 Jun 2003 14:28:14 +0300 (EEST)

> I doubt that the latter (parenthetical requirement) is possible.

Hence why the ordering could be reversed: no modifications necessary for 
working-by-default-for-the-first-try configuration.
 
> see it as being.   What we need to do is minimise the harm, we cannot

I didn't say this would be a bad thing, but we should figure out whether 
folks want to do "local only" or "local + global" deployments (and their 
variations).

The reality affects subsequent decisions, of course, but this should be 
taken into account.
 
> works (when routing cannot get other addresses to work).

True.. in certain deployments, this has some merits.

What I'd like is to look at the problem from all the angles and document 
the tradeoffs and implications of both ways and see from there: not just 
assume that "local = smaller scope" is automatically better.
 
> building networks.  

That includes of course imposing the requirement how you want to build the 
network on other people ;-)

[...]
> Information Queries (from Matt Crawford's draft) ?

You mean that NIQ should be amended to allow queries from that space and 
forget about the TTL=255 security hack?

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Jun 2003 18:45:27 +0700

Date:        Tue, 3 Jun 2003 14:28:14 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hence why the ordering could be reversed: no modifications necessary for 
  | working-by-default-for-the-first-try configuration.

Which is "working-by-default-for-the-first-try" depends entirely upon
how the network is built - in some environments, global addresses might
not work first try (for some applications, I'd be tempted to have
an attempt from any global source addr, or to any global dest addr,
automatically dropped on the floor - and not for any supposed security
reason).

  | You mean that NIQ should be amended to allow queries from that space and 
  | forget about the TTL=255 security hack?

I really meant that NIQ as currently defined, for QTYPE==3, has an "S"
bit in the query that requests "site local" addresses.   Something needs
to work out how that applies (how NIQ applies in general) to these new
kind of addresses.   NIQ is too useful to just allow to wither.

That's as in draft-ietf-ipngwg-icmp-name-lookups-09.txt which is the most
recent I can find.   It has no mention I could see of what address types
should be allowed, nor any TTL==255 hack.   I can imagine that in some
environments restricting NIQ to LL addresses, and/or TTL==255 might be
worthwhile as a kind of security (close to useless), but I certainly can't
imagine the spec ever permitting only that - that would outlaw its use
in other environments where real security (as in IPsec) existed for the
query.

kre

---

From: Fred Templin <[email-masked]>
Date: Tue, 03 Jun 2003 11:25:52 -0700

>True.. in certain deployments, this has some merits.

Deployments that expect to encounter intermittent global connectivity and/or
frequent renumbering events may be better served by preferring local use
addresses over global.

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Tue, 03 Jun 2003 17:16:52 -0700

> frequent renumbering events may be better served by preferring local use

Kre, Fred,

I will argue that prefering global scope (when available) will
_generally_  result in having better chance of connecting.
Yes, I agree with you, there are _some_ cases where this is not
true, but those are not the _general_ case in the Internet.
What we are talking about here is setting up default.
(The I of IETF stands for Internet, not for local networks.)

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 supposed to recognize and give priority to.

Please, keep things simple.

    - Alain.

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Jun 2003 20:59:44 +0700

Date:        Tue, 03 Jun 2003 17:16:52 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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 supposed to recognize and give priority to.

I absolutely agree with this.   Further, I believe that 38 bits of
identifier is plenty for gaining lower collision chances with
non-routable addresses (which is all any of this can possibly achieve).

Hence, I see no real reason at all to stray from FEC0::/10 - and lots
of reasons to remain in that space.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Jun 2003 21:08:50 +0700

| I will argue that prefering global scope (when available) will
  | _generally_  result in having better chance of connecting.
  | Yes, I agree with you, there are _some_ cases where this is not
  | true, but those are not the _general_ case in the Internet.
  | What we are talking about here is setting up default.
  | (The I of IETF stands for Internet, not for local networks.)
 
Having agreed with half of Alain's mail (and splitting this deliberately
because there are two separate points here), let me disagree with this
part.

What will work best depends upon just what is being counted.   If you
count all the possible places I might try to connect, and determine
which address would work, and which would not, you're absolutely right.

But, if you count all the connections I attempt to make, and work out
which address would work, and which would not (or is not best to use)
then you're wrong - because I, and I suspect most people, make huge
numbers of local "connections" compared with the number of remote ones.
(Just to be obvious, sending a DNS request to the local cache is a local
connection for this purpose, and one of those tends to precede each
remote (and many local) connection...)

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.  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 used) which
order I'd prefer actually depends upon the application.  For some,
using the global address is just fine (for some perhaps, even necessary).
For others, it isn't, and the local (more stable, probably) should be
preferred.

kre

---

From: Bob Hinden <[email-masked]>
Date: Wed, 04 Jun 2003 07:29:05 -0700

KRE,

>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 2050.

My preference would be for a larger global ID, but I would like to hear 
what other folks think.

Bob

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 01:04:52 +0700

Date:        Wed, 04 Jun 2003 07:29:05 -0700
    From:        Bob Hinden <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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 2050.

I trust your calculations, so assuming they were all going to be unique,
then yes, 50 years from now people wouldn't be able to have more than 30
or so non-routable /48's each (oh, such suffering!)

But of course, they're not going to be unique, and don't have to be, so in
practice, the limit per person would be much much higher (not quite
274,877,906,944 each, as the user will want to remain distinct from some
others, but perhaps within a few orders of magnitude of that).

kre

---

From: Alain Durand <[email-masked]>
Date: Wed, 04 Jun 2003 15:51:31 -0700

Robert Elz wrote:

>order we select as the default determines which of the two is used.
>
I agree.

>  For
>order I'd prefer actually depends upon the application. 
>
This is true.

> For some,
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.

    - Alain.

---

From: Ole Troan <[email-masked]>
Date: Thu, 05 Jun 2003 00:56:15 +0100

> 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 2050.
>
> My preference would be for a larger global ID, but I would like to
> hear what other folks think.

I agree with kre, stick to fec0::/10.

/ot

---

From: Andrew White <[email-masked]>
Date: Thu, 05 Jun 2003 13:27:36 +1000

Alain Durand wrote:
> require global addresses don't have anything special to do to work.

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 forward addresses out-of-scope.  In this case, either:

- forward names, so that you get all in-scope options, not just the one that
worked for the forwarder.

- accept that your application is now delving into the routing space and
code accordingly.

The other way of looking at it is to observe that 'local' addresses are
proposed as a solution for when 'global' addresses are unavailable,
unstable, or otherwise untrusted.  In other words, if local addresses exist
the general assumption should be that the network wants applications to
prefer them over global ones.  I cannot think of an example for a
non-forwarding connection where this would not be true.

Note: 'prefer' is qualified by the source address selection rules, which
will (among other things) prefer (in order):

- matching scopes over non-matching
- smaller scopes over larger
- longest prefix match

In a multi-addressing environment, applications must be ready to try
multiple source-destination address pairs until one succeeds.  A source
address selection compliant gethostbyname will return the destinations in
preferred order (taking into account available source addresses).  There is
an implementation question on what order the two dimensional destination and
source space should be searched.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 5 Jun 2003 09:33:26 +0300 (EEST)

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 the scope of local 
addresses "global".

And those sites who wish to change the preferences, could either pick any 
one of them, or insert a custom entry in the policy label table for the 
local addresses, causing communication between local-local be preferred 
except for certain special cases.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 5 Jun 2003 09:50:29 +0300 (EEST)

> - accept that your application is now delving into the routing space and

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 firewalls who silently drop 
packets).

This should not be an important issue, but I fear in practice, it is..

[...]

> source space should be searched.

I think the order is specified: destination first, unless the application 
specified the source address explicitly.

---

From: Andrew White <[email-masked]>
Date: Thu, 05 Jun 2003 18:46:03 +1000

> This should not be an important issue, but I fear in practice, it is..

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
theoretically guaranteed to be invalid.

Does that mean that routers that blackhole local addresses (or filters doing
the same thing) SHOULD (or MUST) return 'destination unreachable' messages? 
I'd previously thought MAY.

However, the counter-argument is stability.  IF my local network uses local
addresses and IF another local network leaks their local addresses and IF
these don't get filtered correctly then I get a long timeout.

In contrast, IF my local network uses local addresses then it implicitly
says 'my global address is less "robust"' (for some definition of robust). 
If your global address is more robust then WHY are you using locals?

Again, what is the scenario where you enable local addressing and then
expect applications not to use it for local communication?

Quote from a draft I've been fiddling with for the last couple of months...

   The IPv6 working group has identified three scenarios that would
   benefit from the existence of a local addressing scheme.

   o  Disconnected networks.

   o  Intermittently connected networks.

   o  Stable local addresses for changing ISPs without disrupting local
      communication.

   If we consider a disconnected network to be an intermittently
   connected network that has not been connected yet, all three resolve
   to a single scenario: a network that wishes to maintain a stable
   local address space regardless of the presence or absence of one or
   more ISPs.

Unless I'm missing something obvious, you use a local addressing scheme so
that your local connections can operate independently of the global
internet.  Where is the benefit in making these connections prefer global
addressing?

> specified the source address explicitly.

Checked RFC3484 - source address selection returns exactly one (the "best")
source address for a given destination address.

This leaves an operational quirk.  In general, I want to rank the array in
BOTH dimensions.  For example, I might prefer local-local to global-global,
but I certainly want to try both of them before trying something ugly like
global-local.  However, if I have three local sources, I might want to try
each against the local destination before trying the global destination with
a global source.

This implies some sort of two-dimensional ranking.  It seems the sensible
default is for the application to simply make a connection request using the
domain name and for the host to rank all source-dest pairs and then iterate
in order.  The app may wish to specify some timeouts (eg try no more than 3
dest addrs and no more than 3 sources per addr).

(Note: this latter problem is orthogonal to the local addressing issue, but
is necessary to solve decently if we want more than one address per node).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jun 2003 10:55:50 +0200

> others, but perhaps within a few orders of magnitude of that).

So, how about stating that:

FEC0::/48 is reserved and not to be used. (This is a shot at backwards
compatibility for existing usage.)

FEC0::/11 is followed by a 37-bit number randomly allocated by the user.
(We should recommend a method, and zero is forbidden.)

FEE0::/11 is reserved for future use. (Giving us time to work out how
a fee-paying (pun) registry might work.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jun 2003 10:47:24 +0200

> except for certain special cases.

The problem here is that the notion of scope as a set of embedded circles
is simply wrong. Because of VPNs and hosting centers we will have "prongs"
of enterprise networks extending into physical sites of other enterprises
in an overlapping pattern. There is no simple scoping rule that can
describe this, so there is no applicable default in such cases.

But default preference = global seems reasonable to me.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 17:30:55 +0700

Date:        Wed, 04 Jun 2003 15:51:31 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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, the way I do things generally fits with what you'd
want I believe, but the way you expressed it isn't the way I would.

That is, really, almost no apps "require global addresses" - there are
a small handful in that category.

On the other hand, it is also true, that there are really only small
handful of apps that really want to use local addresses in preference
to global, when both would work.

The vast majority of apps simply don't give a damn - all that matters
is that some address that works now, and is likely to keep working for
the next few minutes, be picked.    Given that (for some networks)
sometimes only the local address will work, and sometimes (for
different networks, or destinations) only the global address will
work, there isn't really any way that a system can choose one or the
other as better, for these apps (most of them) and be correct.  It
needs to be a network setting (more in RA packets??)

My personal preference is that every node should have a global address,
always, and that those addresses should always work (for most purposes)
so for apps that don't care, in the work I have been doing, global
addresses are what always gets used.   On the other hand, for apps that
do care, there is an API that allows them to get local addresses
whenever they work (the API keeps changing as we play with it more
and make different demands upon it).

This scheme works for me, but won't work for everyone.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 17:35:42 +0700

Date:        Thu, 05 Jun 2003 10:55:50 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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.   That is, backwards compatibility
with what?    On the other hand, making it very clear that "I pick 0"
is not choosing a random number would be worthwhile...

  | FEC0::/11 is followed by a 37-bit number randomly allocated by the user.
  | (We should recommend a method, and zero is forbidden.)

That's OK, 37 bits is at least half as good as 38...

  | FEE0::/11 is reserved for future use. (Giving us time to work out how
  | a fee-paying (pun) registry might work.)

We should obviously also reserve F1E0::/11 and F0E0::/11 (and then
someone just needs to figure out how to write "UM" in hex so we
can smell the blood...)

kre

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 6 Jun 2003 15:51:14 +0100

> 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::/10 available.

Mind I'd rather not use them since there could be some advantage in
implementation terms if all of fe00::/8 was known to reserved for
'weird' i.e. scoped addresses.  At least I'd prefer not to have the
registry based numbers within the fe00::/8 range.

DF

---

From: Robert Elz <[email-masked]>
Date: Sat, 07 Jun 2003 01:47:18 +0700

Date:        Fri, 6 Jun 2003 15:51:14 +0100
    From:        Derek Fawcus <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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 "upper 38".   Nowhere does it define what a "site" should be, or
what a site border should be.   It is easy to treat the entire internet
as a single site (no borders) and remain 100% compatible with the SL
definitions.   That's effectively what is being done.
  | 
  | If people are desperate to use a /10 range,  there's always fe00:/10 and
  | fe40::/10 available.

It isn't the size of the range, but that it is reusing address space that
has already been designated.

kre

---

From: Alain Durand <[email-masked]>
Date: Mon, 09 Jun 2003 11:16:04 -0700

>theoretically guaranteed to be invalid.
Operational experience on a production network:
We have seen the results of those timers with different implementations.
They can be up to 3 minutes and 30 seconds per invalid address.
Multiply that by the number of 'published/leaked' addresses (v6 nodes with
multiple interfaces can have many) and you end up with an unusable system.

    - Alain.

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Jun 2003 18:46:55 +0700

Date:        Mon, 09 Jun 2003 11:16:04 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | >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
  | >theoretically guaranteed to be invalid.
  | >
  | Operational experience on a production network:
  | We have seen the results of those timers with different implementations.
  | They can be up to 3 minutes and 30 seconds per invalid address.
  | Multiply that by the number of 'published/leaked' addresses (v6 nodes with
  | multiple interfaces can have many) and you end up with an unusable system.

This general problem has nothing much to do with address forms, and it
is more likely that a host will have lots of global addresses than
lots of local ones (that is, the number of global addresses will normally
be a multiple of the number of local ones - sometimes that multiple will
be 1, sometimes bigger).   It would be rare for a host to have more
local addresses than global (unless the number of global is 0, in which
case this whole discussion is moot).

But I'd hate to think that we were allowing stupid software design to
influence choices, rather than simply striving to improve the software.

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 with no
response, it switches to global.

This relies on several assumptions about the nature of local addresses.

First, they tend to be local - the RTT to a local address should be
fairly small (100ms allows for spans of a continent).  Sometimes
for a diverse organisation, this might result in a global address being
used where a local one could have been (either because 100ms isn't long
enough, or because of packet loss - congested local nets) but that's
no different than "prefer global first" would achieve.   (Work is
currently being done which should lower the effects of this without
delaying applications).

Second, if one local address doesn't work, then it is very likely that
none will (the way we do this, it actually becomes a side effect,
rather than a deliberate act, but anyway).   That is, if one local address
fails, then we don't try others, we switch to global (of course, if
there are no global addresses things are different).   We're going to
need to revisit this if we end up switching from site local addresses
to Hinden addresses, as there the reachability of one local address
really says nothing about that of any other, but for current SLs it does.

The overall effect of this is that the difference to the application
when preferring local first is almost invisible (but we're doing more
to make this even smaller).

There doesn't need to be a huge delay before finally trying a global
address and having it work.

On the other hand, if you try global first, and you're really trying to
reach a local node, for which the global addresses don't work (have been
arranged to be dropped by routers intervening, to force the use of
local addressing) then you really must suffer a long delay - the delay
waiting for a response has to allow for worst case internet RTTs (or
you might fail to find the only address that actually works) along
with retransmits (as while dropped packets locally are usually quite rare,
across the internet they're normal) - and you cannot draw any conclusions
about one global address's reachability from that of another, they all
need to be tried.

kre

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Jun 2003 10:47:53 -0700

>address and having it work.
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...
Note that I've seen some implementation ignoring this
MUST and setting the timer to 12 or 25 seconds,
but never to 100ms.

>about one global address's reachability from that of another, they all
Same issue here, TCP timeouts.

    - Alain.

---

From: Robert Elz <[email-masked]>
Date: Wed, 11 Jun 2003 15:08:22 +0700

Date:        Tue, 10 Jun 2003 10:47:53 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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...

You're assuming that I am actually using a TCP SYN to detect
reachability.   That isn't the way it is done.   We want to make
things work well, not arbitrarily slow them down.

kre

---

From: Alain Durand <[email-masked]>
Date: Wed, 11 Jun 2003 09:07:14 -0700

> things work well, not arbitrarily slow them down.

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 and some only support v4.

	- Alain.

---

From: Robert Elz <[email-masked]>
Date: Thu, 12 Jun 2003 00:40:10 +0700

Date:        Wed, 11 Jun 2003 09:07:14 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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 and some only support v4.

I'll do that sometime later (or send you something in private mail).

But, I am only concerned with the v6 case - the decision to use a v6
address is assumed to have already been made.   If that turns out to
be incorrect, and a fallback to v4 is needed, that would happen just
as you now imagine it happening (and all the variation I'm using would
have changed is that perhaps some IPv6 addresses would have been ignored,
but that's currently assuming "traditional" SL addressing, rather than
the new form, and I'm not sure it will be able to survive - maybe in
a variant form, that is going to take more work to establish).

kre

---

From: Alain Durand <[email-masked]>
Date: Wed, 11 Jun 2003 11:37:15 -0700

Robert Elz wrote:

>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
to make the decision. The apps is returned an "ordered" list that mix
v4 & v6 addresses to try one after the other.

    - Alain.