Subject: RE: Yet another FEC0::/10 proposal

From: [email-masked]
Date: Mon, 7 Apr 2003 08:58:15 +0300

Nick,

> I like the direction Andrew is taking, but how about an alternative
> set of rules which will cope with multiple scopes a bit better. 
> The precise meaning of 'scope' has to be clarified of course,
> but I imagine it can be derived from the top few bits easily enough.
> 
> * A node sending a packet MUST use an source address in the same scope
>   as the destination address (except for Neighbour Discovery purposes)
> 
> * A router MUST NOT forward a packet with different source address
>   and destination address scopes, and MUST NOT forward a packet
>   to an address of different scope than the packets
>   source/destination address scope.
> 
> * A router MUST NOT advertise a prefix or a route to a prefix on an
>   interface which does not have an address with the same scope
>   as that prefix.
> 
> These rules implicitly prevent site-scope packets and routes from leaking
> beyond the site.  Note, for example, that since the site-edge routers
> won't have SL addresses on their outside interface, they won't leak
> SL traffic, and since core routers won't have GUPI addresses, they
> won't transmit SL traffic anyway.
> If it is necessary to connect a site across the Internet, this can be
> done by VPNing / tunnelling.

One question, on the above, where you have text such as:

 MUST use an source address in the same scope

What if we substituted it with:

 "MUST use an source address in the same scope or greater"

That way, if nodes want to insist on using global addresses, then 
that will become a default behavior.

br,
John

--------------------------------------------------------------------
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: Patrik Fältström <[email-masked]>
Date: Tue, 8 Apr 2003 07:58:54 +0200

> that will become a default behavior.

If we have three hosts, A, B and C, and A communicate with B, and B 
with C. Then A know the peer address of B, and B know the one of C, 
but, A doesn't know the one C has. Because of this, A doesn't know 
within what scope C is, and because of this algorithms like the one 
above doesn't work. An application can not make a choice based on 
scoping.

    paf

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 9 Apr 2003 08:08:32 +1000

> above doesn't work. An application can not make a choice based on 

Um.  So this is a protocol where B is passing C's address to A, so
that A can talk directly to C?  Sounds ... interesting ... but 
maybe this situation can also be fixed with scoping rules, if we
require all addresses to be of the same scope.

	A -------- (B_A B_C) ------- C
         \__________________________/

(B_A is B's source address for talking with A.  B_C is C's source
address for talking with C.  I figured I'd better separate them 
just in case. S(X) just means "the scope of X".  Sorry for dragging
my own notations into the light of day ...)

Eg: with the scoping rules I proposed earlier,  S(A) MUST= S(B_A) already,
and S(B_C) MUST= S(C) already.  So if your application ensures that
S(B_A) = S(B_C), then S(A) = S(C), and there's no problem.  

BTW, did you have a specific application/protocol in mind?  I'm
guessing something p2pish with a central despatch server ...

-----Nick

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 9 Apr 2003 08:21:25 +0200

On onsdag, apr 9, 2003, at 00:08 Europe/Stockholm, Nick 'Sharkey' Moore 
wrote:

> that A can talk directly to C?

Yes.

> Sounds ... interesting ... but

Yes, B might detect that the scope is different, but what should B do? 
B doesn't know what some other address of A (in a different scope) is. 
B can only say "No", which might be hard if A and B already have a 
communication going, and then want to add C.

> guessing something p2pish with a central despatch server ...

FTP and SIP. Especially SIP (ftp is not used in that mode much the last 
20 years...).

    paf

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Apr 2003 08:14:26 +1000

> Yes, B might detect that the scope is different, but what should B do? 

Well, if B only corresponds on addresses in one scope, that problem
goes away.   Presumably, if you _really_ want B to see two scopes,
B needs to keep two client lists and never the twain shall meet.

I think, in short, that this can be easily solved with 
1) strict scoping rules at L3  and  2) sane setups in the application.

> FTP and SIP. Especially SIP (ftp is not used in that mode much the last 

I'm not sure whether to be glad or not that FTP is not the only
protocol doing this sort of thing ...

-----Nick

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Apr 2003 09:49:16 +0200

On torsdag, apr 10, 2003, at 00:14 Europe/Stockholm, Nick 'Sharkey' 

> 1) strict scoping rules at L3  and  2) sane setups in the application.

As SIP is global voice over IP which ultimately means that A, B and C 
can be any node on the Internet, this imply only global scope can be 
used for applications, and limited scope can only be used in very very 
special and controlled environments (which I would classify is _not_ 
"Internet" but instead "some other thing which happens to use IP as the 
protocol").

This is _exactly_ why I ask myself what Site Local is really solving, 
as it is not usable for applications, and why I therefore think Site 
Local must be deprecated, as the problems (non-apps) people think Site 
Local is solving MUST be solved by using different mechanisms.

     paf

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Apr 2003 18:19:50 +1000

On Thu, Apr 10, 2003 at 09:49:16AM +0200, Patrik F?ltstr?m wrote:
> used for applications, [...]
> as it is not usable for applications, [...]

I'm not sure we can say "Not useful for SIP" == "Not useful for
applications".

-----Nick ... who knows nothing whatsoever about SIP, mind you ...

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Apr 2003 16:40:26 +0700

Date:        Thu, 10 Apr 2003 09:49:16 +0200
    From:        <[email-masked]>
    Message-ID:  <[email-masked]>

I haven't been following the ipv6 wg list (the ipng list) for about 6
months now (just lack of time), so I'm not really aware what started
this silly discussion.

But this has to be the worst piece of rational argument I have ever
come across in any forum, just about anywhere, by someone who should
know better...

  | As SIP is global voice over IP which ultimately means that A, B and C 
  | can be any node on the Internet, this imply only global scope can be 
  | used for applications,

Huh???   I see a red car, therefore only red can be used for cars.

To disprove "only global scope can be used for applications" all one needs
is to find an application which can use other than global scope.

Well, take ssh, web browsers, NFS, telnet, SMTP, ....

Examples of applications which work just fine over SL addresses.

Now, if someone was stupid enough to be claiming that all applications will
work using SL addressing, your counter-example would be enough to
disprove that.   I suppose it is possible someone who wasn't thinking
might have made such a claim that I haven't seen, though I doubt it, as
it is patently obvious that SL addressing can't be used anytime the
communications are to go outside a site.

But in any case that isn't what you're saying ...

  | and limited scope can only be used in very very 
  | special and controlled environments (which I would classify is _not_ 
  | "Internet" but instead "some other thing which happens to use IP as the 
  | protocol").

by definition, they only work inside a site.   I don't think that's
very special (every node can be, if it wants a site, every collection
of a few nodes on a LAN certainly can be).   Controlled - yes, of course,
SL addresses don't want to escape a site.

  | This is _exactly_ why I ask myself what Site Local is really solving, 
  | as it is not usable for applications,

That is obviously false, I use SL addressing for applications every day.

  | and why I therefore think Site 
  | Local must be deprecated, as the problems (non-apps) people think Site 
  | Local is solving MUST be solved by using different mechanisms.

Go ahead and propose some different mechanism that works nearly as
well, as universally, and with as few problems, as SL addressing.

Some of the problems you need to solve, before we simply assume that
there *must be* some other solution that someone else is required to
find, and abandon SL addressing are ...

How do I keep my connection to my NFS server when all my global addresses
change?

How do I avoid having to reconfigure my browser to know a new proxy
server in the same circumstance?

(etc).   These are situations where SL addresses work just fine - if
I assign SL addresses to my NFS server, and web cache, then I can use
those addresses, and know they'll remain stable, isolated from all
events other than those I decide to instigate myself (ie: if I decide
to renumber my internal network, split subnets etc, then if I'm not
careful, some of those addresses might alter) - nothing imposed by the
outside world can make that happen.

Please note, one non-answer to this is to redefine site local addresses
so they're global, but not routed.   That solves none of the problems
(the addresses still can't be used in your SIP example for instance)
but imposes some extra address assignment bureaucracy on everyone.
We already have the one (chain of ISPs) that can't be avoided for
topological addressing, we don't need another one (this was why we
never had any global non-routable addresses in the design in the
past).   Personally, if a system to make this work can be found, I'd
love it - globally unique non-routable addresses solve all the problems
that non-unique SL addresses do, and perhaps a few more (though now
we have those extra 38 bits available for SL SLAs there really isn't
almost anything that SL as we have it now cannot do).

Also note that even geographic address assignment plans (like Tony Hain's
very clever proposal) don't avoid this bureaucracy - they allow some
sites to avoid it, but require it for others - something is needed to
adjudicate between multiple sites that are all in the same geographic
area (apartments in an apartment block for example).

I doubt that there is some other solution, but if you can find a way
to make addresses stable, without making them non-routable (which makes
them equivalent to SL as we now have it) then please, tell us all what
that solution is.   Until you can do that, please stop telling everyone
that it must exist, and that someone else is required to find it.

On the other hand, there clearly are applications that never want to
use SL addresses.   There are others for which SL addressing is
workable, but for which the benefits are negligible, and so using them
isn't worth the effort.   And there are others for which using SL
addresses, when appropriate, can be a big win.

So, what seems to be needed is a way for the application to indicate
which of those groups it is is - and really that just means, whether it
wants to use SL addresses, if they'll work, or not.

That seems reasonable to me.  Abandoning SL addresses because there
are a class of applications for which they don't work is absurd.

The other issue is multi-site nodes.   That's something that could
be dropped.   There were arguments in the early days about where
site boundaries should be drawn - through links, through nodes, or
only through DMZ's.   Allowing links in multiple sites is impractical,
as then packets would need to carry site IDs, and that makes a mess.
Allowing nodes to be in multiple sites is possible (that's what we
have) though it adds some complications.   Forcing there to be a
no-site link between nodes in different sites (and only one site for
any node) makes SL addresses look just like globals, for almost
all purposes - but means that exchange points have a harder time
operating as a site - really they want to be a local site for the
exchange itself, so it can use stable addressing on all of its
local links, but every ISP owned router in the exchange also wants
to be part of that ISP's site).   This is the argument that swayed
the decision in favour of multi-site nodes.

Given that applications (and everything except routing protocols) need
to deal with scoped addressing because of LL addresses (I'm assuming
there's no-one here insane enough to be planning to deprecate those)
and that multiple instances of routing protocols isn't something new
anyway (and other methods can also be used, and I believe have been),
there are really very few drawbacks to allowing multi-site nodes, so
I see no reason to change that aspect of the spec - but it is one that
could perhaps be changed (the loss isn't very great).

Aside from that, Site Local addressing MUST remain as it is, until
someone solves the routing problems which prevent non-topological
routable addresses from working (even the geographic addressing schemes,
as they're proposed to be used for routable addressing, require the
topology be set up to match the geography - at least coarsely).

Anyone proposing to remove the one locally routable, stable, addressing
form that we have, has to be able to propose a replacement, otherwise
we simply have to retain what we have now, which works.   That is,
people used it, and yes, it works!

kre

ps: I'm a co-author of a paper that is to be submitted (somewhere, I don't
personally really care much where it is going) which describes exactly how
we use SL addresses, how easily they're made to work, and gives at
least some idea on how the API can be managed to allow all of this, though
I'm not yet sure we have that quite right yet - there's still work being
done.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Apr 2003 22:24:48 +0200

> SL addresses don't want to escape a site.

Ok, my brain run away, you are right in what you say Robert.

What I have problems with is the ambiguity between for example site 
local and global address for the same host together with scoping (for 
one of them).

Yes, I agree there are issues with for example your NFS connection when 
you get new global addresses (I think your site can keep your addresses 
when it is disconnected, but you might end up having problems when it 
connects to something again). But, I don't think that is a problem 
which should be solved with ambiguity and more addresses.

I see two paths out of this:

(a) Fix SIP, NFS, TCP, whatever so the protocols can handle a 
renumbering "event" when it happens. If we use addresses both for 
routing and identification, and the identifier because of this changes 
because of routing topology changes, then the protocols must be able to 
handle such an event.

(b) Differentiate routing from identifier (much easier for me to point 
at as I have _absolutely_no_clue_ what that means for IP addresses, 
routing etc. I know it is something very very nice in general to not 
overload the use of some identifier from work in apps area for some 
years now.

To conclude, I used a bad example, sorry. I wanted to show how hard it 
might be for a SIP-like application to know what address to use. That's 
it.

     paf

---

From: Greg Daley <[email-masked]>
Date: Fri, 11 Apr 2003 09:26:58 +1000

Hi Patrik,

Patrik Fa"ltstro"m wrote:
[Nick's post cut]
 > "Internet" but instead "some other thing which happens to use IP as the
[rest cut]

While I'm sure that SIP is primarily focussed on the Internet,
most VoIP systems run site-internally today (albeit with H.323).
These systems may not even be on public internets
(I would consider running a VPN not reachable from
my corporate network's address range for voice
communications).

In these cases, a locally scoped address space may be
a valid choice, since global routability isn't a goal.

Greg.