Subject: Re: [Tsvwg] Regarding IPv6 address scope

From: David Lehmann <[email-masked]>
Date: Fri, 01 Mar 2002 07:53:31 -0500

Randall Stewart wrote:
> A couple of thoughts:
> 
> If I send From/To a link local...
>   - I can NOT necessarily include all my other link
>     locals because:
>      a) How do I know that my peer also has interfaces
>         on the same lan's that I do?

You don't.  But that is the same case with multihomed IPv4
addresses.  How do you know that the peer can route to all
of your bound addresses?  Answer: You don't.  However,
the heartbeat mechanism will discover that and mark those
destinations as unavailable.  If user did know which 
addresses the peer could reach, the user should
bind to only those addresses.  This one good reason that we give
the user the flexibility to bind to certain addresses.

Also, I don't think it is uncommon to have two machines, acting
as a cluster, being connected together by multiple
LANs (e.g. ethernet crossover cables).  Are you saying
that SCTP/IPv6 cannot accommodate this configuration?

>      b) Even if I know that my peer DOES have interfaces
>         in common with ALL my interfaces, how can I
>         know or inform my peer what is the valid scope id
>         for his end of our common interfaces... its not
>         a problem when he receives from a link local, he can
>         dig down and find the scope id off the receive interface..
>         but the other interfaces unless the local endpoint is
>         somehow configured... and it still can tell the peer..

The local endpoint would have to know to bind only to the addresses
that the peer can route to.  However, if the local endpoint binds to
all the available local addresses, IMHO, SCTP is compelled to obey the
user and put all the bound addresses in the INIT.  In such a case, the
heartbeats will figure out which destinations are useable.

>         Remember I may be using fe80::1 on say my second interface
>         but my peer may have interfaces a, b, and c. Maybe my
>         second interface is on b, but my peer also has a neighbor
>         (not me) on c using the same address.  If he gets a INIT
>         chunk from me listing fe80::1 he has no idea if I am the
>         neighbor on b or c?.

The peer's neighbor should have a different local addresses, since
the IPv6 local addresses are derived from the hardware addresses.
In the unusual circumstance that the hardware addresses are the
same, couldn't you add additional unique IPv6 addresses to the
network interfaces?

> For the above reasons our current BSD implementation in KAME
> will only allow link locals to be included if:
>    - You are sending to a link local.. but the link
>      local is NOT put in the list of addresses.. it gets
>      in by inference as being a source address on the INIT/INIT-ACK.
> 
>    - Or if you are sending to a loopback address. This we have
>      not played with to much though.

I don't think that this is practical, given my cluster 
configuration above.

> For site locals its a similar thing.. I must have a site local
> for a destination before I allow the scoping to list site locals. Right
> now we have only one site.. but once you start getting the use of
> scope'd sites.. the same issues start to creep in like link locals.

My argument is the same here.  The _user_ should decide which addresses
that it wants to send to the peer by binding to those particular addresses.
I do not think SCTP should be making these decisions.

> Its really a gummy mess.. and we do need to think on this and
> have another spin of the draft...

Agreed.

-David

---

From: Randall Stewart <[email-masked]>
Date: Fri, 01 Mar 2002 11:22:09 -0600

David Lehmann wrote:
> of your bound addresses?  Answer: You don't.

David, I think your answer is wrong here.. you do to. If the
address is NOT a private address aka 10.x.y.z or one of the
others (can't remember the class b/c prefixs to them).. 
IT IS SUPPOSED to be a public address. Now it is
in theory possible that someone will poach a non network address
but this is a different issue.. A private address is a special
criter that should also have rules applied to it for scope
escapement...

>                                                However,

No that is NOT what I am saying.. You CAN take advantage
of a singly homed link local cross-over; You won't be able to
take advantage of the multi-homed cross-over cables though..

This is what we have discussed as the Dentist's office problem.
The dentist wants to connect his machines and knows nothing
about any of this IP stuff.. He hooks up his machines and wants
them to work. He CAN get the machines to talk with this
scheme.. but if he wants multi-homed machines he needs to start
doing something with a site or global address....

> heartbeats will figure out which destinations are useable.

No, you have obviously not played with an IPv6 stack yet (lots of
fun in store for you .. :>). This just does NOT work. 

This is because you MUST specify which link a link local
goes with in the scope id. Remember the SAME link local address
can represent DIFFERENT machines on different networks... How
do you know which one from an INIT or INIT-ACK goes with what
interface.. answer is you CAN NOT. And worse the peer could not
tell you this because it is a local kernel issue as to which
interface gets assigned which link local scope id... so in theory
between boots of a machine the scope id that needs to be present
can change...

> same, couldn't you add additional unique IPv6 addresses to the

No sorry it is NOT this way. I can generate link local addresses
ANY way I wish. I as a administator can assign alternate address
fe80::1 (besides one created by my machine automatically.. if it
does this .. which is optional). In fact many admin's do this
since it is a pain to type in ALL those numbers when you can
just put in FE80::1 and FE80::2 etc.. instead of
FE80::xxxx:xxxx:xxxx:xxxx:xxxxx:xxxx:xxxx

Sorry the sad reality is that you CAN NOT depend on EU64 numbers to
save you here. A link local is ONLY unique on a particular LINK...

> I don't think that this is practical, given my cluster

Sorry it is the way IPv6 works.. If you want clusters that are
multi-homed
you will need to look at other ways of putting them together
such as a site-local... or just assign global addresses...

> I do not think SCTP should be making these decisions.

Sorry it does NOT work. You have to use some heuristic in selecting
what addresses go in the INIT/INIT-ACK BESIDES just what is bound.
Otherwise
you will be giving out unsusable address or worse have a situation
where you will knock down your own association by having your peer
HB to a guy that is NOT you.

You must assure that any address you list does NOT escape its 
routable scope...  This really should also be true for IPv4 private
addresses as well...

> > have another spin of the draft...
R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: David Lehmann <[email-masked]>
Date: Fri, 01 Mar 2002 16:22:24 -0500

> take advantage of the multi-homed cross-over cables though..

That is what I thought you were saying... but I still find
this strange.

> fun in store for you .. :>). This just does NOT work.

That's right.  How did you guess? :-)
Actually, I have been playing with IPv6.  I tested it
om my daemon and kernel implementations, but only
over one IPv6 interface.  Now I need to move onto multiple IPv6
interfaces. This why I am now reading these documents.

Your insight is appreciated.

-David

---

From: Randall Stewart <[email-masked]>
Date: Fri, 01 Mar 2002 17:40:22 -0600

It is a very strange situation I do have to admit.. but
without some sort of external information (which I don't
think is even available) I think we are constrained
to use only Link Locals as source/destination addresses
and never in the address lists. Site locals may end
up the same way if the IPV6 group does site scoping
as well.. sigh..

R