Subject: RE: [Tsvwg] RFC2960bis

From: [email-masked]
Date: Tue, 8 May 2001 09:21:51 +0300

Hi Lyndon,

> We would also like to add in a number of clarifications that have been
> identified during the past SCTP bakeoffs, and documented in 
> the draft on bakeoff results
(draft-stewart-ong-sctpbakeoff-sigtran-01.txt):

I concur with the items listed below, but ...

> These are the main clarifications found in the bakeoffs (the 
> latest bakeoff did not identify further issues except one 
> regarding IPv6 that will take more work).

I strongly suggest that we try to get the support for IPv6 right
in the BIS draft, for a very practical reason.  SCTP is a protocol
that will be deployed in many 3GPP networks, which are scheduled 
for later this year.  IPv6 is also a key component of this.  I 
think the time is now do this right.

I'll gladly pitch in on this, and might even have some resources
to play around with different proposals in the lab here, if needed.
I can also ping the IPv6-heavyweights around here to comment on
solutions.

What I would need, however, is a brief summary of the problems
& possible solutions.  I have a general idea of what they are ...

John

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 08 May 2001 08:38:08 -0500

> & possible solutions.  I have a general idea of what they are ...

John:

The problem is not for lack of solutions :> 

What is at issue is address selection and scoping.. i.e. what
addresses do you put in the INIT and INIT-ACK?

One agreement we reached is:

* You never place a Link-Local address within an INIT or INIT-ACK. The
  reason being is that you MUST receive a packet in the FROM field of
  the IP address to really know what interface the Link-Local belongs
  to. So the only way to get an association to include Link-Local
  addresses is to send an INIT TO a Link-Local address and then respond
  back TO the sender of the INIT of course using the link-local. The
rules for
  IP address selection will cause you to add the Link-Local to the
association.

The problem we have is with Site-Local addresses....

Two methods showed up in the composing of a INIT:

A) Scope the addresses so that if I am sending to a Site-Local,
   include all of my Site-Local and Global addresses... If I am
   sending to a Global address, only send the global addresses I hold
   in the INIT.

or

B) Always send your Site-Local and Global addresses to a peer.

Of course the response with an INIT-ACK had similar rules:

1) Scope the addresses based on if a Site-Local was included in
   the INIT... if so include your Site-Local address.

or

2) Always send your site-Local and Global addresses in the INIT-ACK.

Method B/2 is simpler, and takes less work. It depends on the
HeartBeat to detect that a Site-Local address is NOT reachable
from two seperate sites. 

Its down side is what happens if I send you an INIT with my site
local (from cisco to nokia... i.e. not the same site) but I list
my site-local addresses. You pick them up and send me back your
site-local
addresses. But then somewhere on my site someone has used your
site-local address,
guess what happens on my first HB to "your site-local" address? I get
an OOTB abort knocking down the association..

And considering that IPv6 addresses are a long typing in type of thing
:/
admin's will all probably use the site local address to be something
novel
like ff01::1 and ff01::2 etc... very bad :<

Method A/1 has the decided advantage of preventing the above bad
behavior at
the expense of another problem. Lets say I send a INIT to Steve
Deering's machine.
...(see Steve, not only do I want your opinion.. I also want your
machine :->)...
I specify his global address since that is all I know.. but we are on
the same
site. Now I do have a redundant network as well, but it is site local
only with
no global scope. Guess what, I loose the use of this network since I
INIT'ed to
the global address. If I INIT to the site-local then I get use of both
networks...
The original code I wrote implemented the above A/1 but in order to make
things
work properly at the bakeoff I commented out a lot of it to work like
B/2..

The real question is which one should we use? I lean towards A/1 but
others
leaned toward the B/2... What we thought we would do is write a seperate
draft defining the problem and address it to the IPv6 community. In
particular
the multi-homing IPv6 group as well as the IPv6 WG itself... and see if 
they had some advice/opinions..

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 May 2001 16:04:29 +0200 (CEST)

>   IP address selection will cause you to add the Link-Local to the

I think the above is too restrictive and I don't see a need for being so
restrictive.

The problem you need to avoid is to have the link-local or site-local
address contained in the payload of the SCTP chunks (INIT and INIT-ACK)
not "escape" their routability scope.
For the IPv6 source and destination addresses (in the IPv6 header)
this is handled by the routers at the scope zone boundaries checking
both source and destination.

I believe you can build constraints for the INIT and INIT-ACK using that fact.
For instance,
 A implementation MUST NOT include a link-local address in an INIT or INIT-ACK
 unless that message a link-local address in the source or destination field
 (or both).
 [And the same for site-local]

Does SCTP need constraints in addition to the above?
draft-ietf-ipngwg-default-addr-select-03.txt
should cover the relationship between the source and destination as well
as the order at which SCTP should try the addresses during connection
establishment.

   Erik

---

From: Randall Stewart at work <[email-masked]>
Date: Mon, 14 May 2001 09:24:48 -0500

Erik:

Some questions for you... 

> not "escape" their routability scope.

Agreed.. and that is what I was attempting to do :)

>  unless that message a link-local address in the source or destination field

Ok, this one I have different in the current BIS rules (which all may
be coming out until we get NG review).... but this leads me to a
question for
you...

If I allow link-local in the INIT/INIT-ACK list how do I use them?

I tried to figure this out when I coded it and I could find no
way to do so... 

The reason being the scope-id is only set for the address
the packet came from/goes to. Any link-local's list in the INIT/INIT-ACK
(other than the address I received the packet from) I don't know
how to reliably figure out which scope/interface the address belongs
to.... I suppose one could grub through all the neighbor lists
but this may find duplicate results.... 

If you think its ok to list link-local if to/from is link local
I can see this has exceptable.. I don't know how to make it work...
but I can live with it (since I don't think you can make it
work reliably and black holes seem rather unlikely since the
addresses seem to be auto-configed with IEEE numbers for
link-local)..

>  [And the same for site-local]

The above i.e. you don't list site local unless the to/from is a
site local is EXACTLY what the BIS document has in it right now.
This is the main point that Jonathan Woods and Kacheong Poon object
to...

Site-local is the one I had the main problem with... without proper
treatment you will get a black-hole... 

Can you please look at the current rules for site local (I can
send the whole rule set offline to you... let me
know if you want it..) and see if it looks ok? 

R

> Does SCTP need constraints in addition to the above?

I don't think so...

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 May 2001 16:57:48 +0200 (CEST)

> If I allow link-local in the INIT/INIT-ACK list how do I use them?

If you solve the leakage issue i.e. a link-local address contained in
an INIT/INIT-ACK can't escape beyond that link then 
an implementation knows that the link-local addresses contained in the packet
apply to the same link as the link where the packet was received.

> but this may find duplicate results.... 

If you have an implementation that sets sin6_scope_id when one or both
of source and destination is link-local [some implementations might only
do this when the source is a link-local] then you would just use the
scope_id with the link-locals that were in the INIT/INIT-ACK.

> This is the main point that Jonathan Woods and Kacheong Poon object

I thought the document talked about excluding site-locals unless the
destination is a site-local. In my idea it is only necessary when neither
source nor destination is site-local.

   Erik

---

From: Randall Stewart at work <[email-masked]>
Date: Mon, 14 May 2001 10:52:14 -0500

> apply to the same link as the link where the packet was received.

But them what is the point of listing the link-local addresses then
if you can't list your other network card link-locals? The
normal rules of processing will automatically pick up source address
in the address list of the peer... I think I am missing something..

> scope_id with the link-locals that were in the INIT/INIT-ACK.

Again.. this means the link-local(s?) in the INIT/INIT-ACK would all be
to the same NIC card... The sender would have to assure that no other
link locals except the scope being sent to would be in the
INIT/INIT-ACK.

This effectively means you can only list the link local address that
you are sending from... unless of course you have other link local's
bound
to the same interface.. which is possible but I am not sure you gain any
multi-homing capabilities by this... 

I can see trying to craft some verbage saying that you are allowed to 
list other link-local addresses if they are bound to the same scope..
even
though I do miss the benefit...

> source nor destination is site-local.

Yes, I was not thinking source... can you send to a global and source it
from a site-local? Will this work?  

If so, then I would not be adverse
to tweaking the wording so that the source or destination of the
INIT/INIT-ACK
would be required to be a site-local.... 

R
P

---

From: Randall Stewart at work <[email-masked]>
Date: Mon, 14 May 2001 13:55:11 -0500

> source nor destination is site-local.

Ok, after a sidebar conference call... I do now know a reason why one
may want to source from a site-local destined to a global... And the
ugly reason is... NAT.

If one has a NAT, for whatever reason, then your source MAY want to
be a site-local... destined to a global...

Of course then we would still have the problem of unreachable
site-locals
in the INIT/INIT-ACK list... but I guess a "good" NAT would reach in
and tweak these... yuck! I hate NAT!!!

Now on the other hand, let us assume for some other un-thought of reason
you sent a INIT/INIT-ACK with a site-local in the source. You are
required
to respond to the source so if routers/hosts let this To:global
From:site-local
be sent, the poor receiver would send back its answer (say a INIT-ACK)
and of
course would either NOT be able to reply OR some other host (on the
local site)
would drop the (in it's view) invalid INIT-ACK...So I think no matter
which
source/or destination is site-local.. we do not have a black-hole
problem and
I am convinced its ok...

R

---

From: Jim Bound <[email-masked]>
Date: Mon, 14 May 2001 15:06:23 -0400 (EDT)

Randy,

I object to sending a site-local to a global as a default here and for
IPv6 sourese addr selections.  Erik and I completely disagree here I
think.  And we both have written a lot of code for v6.  I think for SCTP
it is even more UNACCEPTABLE.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 14 May 2001 15:02:44 -0400 (EDT)

Randy,

The default addr selection draft cannot apply toe the address parameters
in all cases only the implicit ones in the IP header. Also the reason it
is still a draft is because not all agree on all the algorithms.  

But it is a good draft to look at.

I believe your rules support exactly what Erik wanted in his mail.;

Erik; have you read all the mail threads............????
Randy's fix will work with real code and we can use it for IPv6 too.

regards

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 May 2001 00:36:51 -0400 (EDT)

Erik,

> apply to the same link as the link where the packet was received.

We cannot assume the address parameters passed in the list are for the
link the IP header for the SCTP association came in on so what you say
will simply now ork.

> > I tried to figure this out when I coded it and I
could find no > > way to do so... 
> > but this may find duplicate results..... 
> 

The sin6_scope_ID is local to that machine.  There is not context for the
sin6_scope_ID from the peer sending the INIT to the peer receiving the
INIT-ACK.   There is no context of "link" or "site" in the address
parameters for the SCTP association and no way in IPv6 to pass such
context in IPv6.  Nor will there be.
 
> source nor destination is site-local.

In the IP header yes.  That is exactly what Randy's algorithm does.
ANd it should be a MUST.

regards,
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 09:39:02 +0200 (CEST)

> in the address list of the peer... I think I am missing something..

Ah - you might have been trying to solve something unsolvable.

The reason for including more than one link-local address 
is because each end might have more than one interface attached to
the same link and including the link-locals for all interfaces 
improves availability using SCTP.

You might have been trying to solve something unsolvable - having a
packet sent from link local address Ax to link local address Bx
on link X refer to link-local addresses that the nodes might have on
a different link (Y) has lots of problems. How can you tell whether
(say) Ay and By are indeed on the same link? The link local address look
the same and there is no coordinated name space to name the links
(sin6_scope_id is just a local index for each node) thus unless
you send a packet from Ay to By (as well as from Ax to Bx) and get replies
do you know that Ay and By are on the same link.

(One could envision trying to infer from the global addresses assigned to
the interfaces whether or not they are on the same link. But that isn't
robust since things like mobile IPv6 or proxy ND might make it look
like an address is in the same on-link prefix even though it isn't reachable
using link-local addresses.)

> link locals except the scope being sent to would be in the

Again - there could be multiple interfaces attached to the same link.

> from a site-local? Will this work?  

The address selection rules basically say that it is worth trying that
combination but if there is a better "match" between source and destination 
then try that first. Thus the rules say that sending to a global address with
a link-local source is also worth trying - but after trying other alternatives.
> would be required to be a site-local.... 

ok.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 09:58:41 +0200 (CEST)

> may want to source from a site-local destined to a global... And the

Never crossed my mind but perhaps there are others that have such concerns.

The fundamental philosophy embodied in the rules in
draft-ietf-ipngwg-default-addr-select-03.txt
is that the goal is to communicate thus it makes sense trying all
address combinations that can possibly communicate with the peer, but
trying them in such a order that the more desirable as well as more
likely combinations to work are tried first.

For example, if both ends have both site-local and global addresses
it makes sense trying the site-locals first since that combination is
more desirable (since it isolates the communication from site renumbering).
If the sender has a global and a link-local address and the peer has only
a global address then the <global, global> is tried before the <link local, 
global> combination since it is more likely to work.

> source/or destination is site-local.. we do not have a black-hole

A packet with a site-local source will not leave the site
since that would risk the reply to such a packet to be misdelivered to
another node which has the same site-local address but is in a different
site than the original sender.

See RFC 2373:
   Routers must not forward any packets with site-local source or
   destination addresses outside of the site.

And draft-ietf-ipngwg-icmp-v3-00.txt (expired) has added:
    - Added "beyond scope of source address" message to the family of
      "unreachable destination" type ICMP error messages (section 3.1).

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 10:09:16 +0200 (CEST)

> it is even more UNACCEPTABLE.

I know we disagree. I think the rules I suggested to Randy
will avoid having this discussion in two places - let's have that
discussion on the default address selection draft and let's try to make
the SCTP spec refer to that document.
Thus avoid having the SCTP spec bring out issues
like "is sending to a global with a site local source ok" in
TSVWG in addition to having that discussing in IPNGWG.

But we do need to get closure on draft-ietf-ipngwg-default-addr-select
in IPNG WG.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 10:05:06 +0200 (CEST)

> Randy's fix will work with real code and we can use it for IPv6 too.

No but I tried to real all the mail on this thread (to the extent I could find
them from those emails that talked about the checksum issue).

I have no doubt something can be made to work - the question is what the
right split is between what SCTP needs to specify and what goes into
the default address selection document.

My view is that SCTP clearly needs to specify what addresses are carried in
the INIT and INIT-ACK to not violate the assumptions around the
routability and uniqueness scope for the link-locals and site-locals,
but that it should do so by deriving the rules, and to the largest
extent decoupling the rules, from whatever rules and recommendations will
get rough consensus for the default address selection document.

Also, I think SCTP (the spec perhaps, but definitely implementations)
need to take whatever ordering rules and recommendations in the default
address selection document into account when deciding what order to
try alternate paths when retransmitting.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 10:17:57 +0200 (CEST)

> link the IP header for the SCTP association came in on so what you say

I don't quite understand what you are proposing.
In order for things to work we must prevent that link-local and site-locals
leak outside of their link and site, respectively.

There are multiple ways to do this. A simple one is to completely
ban using link-locals and site-locals with SCTP.
If we don't want that approach I think implementations need to
be aware of which link a packet with link-local source or destination
arrived on (just like TCP implementations need to do today to work
with link local addresses on nodes attached to multiple links)
to be able to send the INIT-ACK back out the right interface.
Going from that to applying the same interface id (sin6_scope_id) when
using any link local addresses contained in the INIT/INIT-ACK
seems like it would work and not too difficult to implement.

> context in IPv6.  Nor will there be.

Agreed.

  Erik

---

From: Randall Stewart at work <[email-masked]>
Date: Tue, 15 May 2001 08:56:18 -0500

> using link-local addresses.)

I did reach the conclusion that it was un-solvable, the hard way :0

Now, I have a question for you. If I have two interfaces on the same
lan. I get two link-local addresses that lead onto the same wire.. so
far I am with you.

Now  lets say for grins and gigles that they are 

FE80::1
and
FE80::2

(I don't like typing all those long strings either :>)

Now I send you a INIT-----> from:FE80::1 ---> to:FE80::your:mach:ineI:d

You receive it and thus know the scope-id on your local machine of
FE80::1

Now This all works fine, I can buy in to the fact that your machine
can try either address and get to me from your addresses.

FE80::your:mach:ineI:d

But here is the 64,000 Dollar question....

How do I know to list FE80::2 into the association on the outbound
INIT? 

From my persepective it is a different scope-id... nothing coorelates
these
two to be on the same network right?

It is just as likely that they are on opposite networks (for even more
redundancy .. besides the cards). Now lets just say I include them
anyway... and they ARE on seperate lans...

Now, you respond to FE80::1 and of course, no problem use the scope
of the received interface... the association comes up..

Now we are back in the same situation for site locals...

You will send a HB to -->FE80::2 with the scope-id set the same as
for FE80::1 and one of two things will occur:

A) You will do neighbor discovery and find it is an unroutable host...
no
   problem this is the best scenario..error returns and the FE80::2 is
marked
   unreachable..

B) You actually find a machine on this link that is FE80::2 (someone
else who
   does not like to type long Ipv6 addresses) and you will get back
   an ABORT. aka the black-hole problem..

Now I admit (B) is less likely in the link-local case since most will
currently
use auto-confuration for this puppy and thus get some horribly hard
thing
to type has the link-local :)

But there is a chance of B happening... right?

R

---

From: Randall Stewart at work <[email-masked]>
Date: Tue, 15 May 2001 08:59:08 -0500

>       "unreachable destination" type ICMP error messages (section 3.1).

The above in RFC2373 is great! This means that if I place a site-local
in the source (addressed TO a off-site global), I will get an
unreachable
error.

So I have no problem with the tweak to say source/or destination is a
site... include site locals...

R

---

From: Randall Stewart at work <[email-masked]>
Date: Tue, 15 May 2001 09:02:52 -0500

> But we do need to get closure on draft-ietf-ipngwg-default-addr-select

Jim:

Considering that IF someone sends 

Site-Local ----> Global

and the Global is NOT on there site, you will get an error back..
then it does not matter (from an SCTP persepective) that you
include site-local's in the INIT.

Now for the actual validity of doing the above the NG group can
decide that... I don't want ANY part of that friendly discussion :)

I think the only thing left here to resolve is the link-local... I
am still unsure about the link-local issues that Erik proposes..

R

---

From: Randall Stewart at work <[email-masked]>
Date: Tue, 15 May 2001 09:05:12 -0500

> seems like it would work and not too difficult to implement.

I still have a possible problem with this... aka my earlier email..

R

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 May 2001 11:25:37 -0400 (EDT)

Erik,

> try alternate paths when retransmitting.
This is where we don't agree.  More later.  SCTP has different properties.
I will write up technical postion why.  But one should NEVER prefer a
site-local over a global assuming a NAT-PT box for Ipv6 exists.  I hope we
can agreee on that.

I will get back to you as I can.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 May 2001 11:27:57 -0400 (EDT)

I think we can do it here because its is a minor subset of IPv6. In IPng
the SCTP learning curve will be to great.  Let me post my tech position
before we give up here.  I think this can be cleared up quickly.

regqards

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 May 2001 11:45:44 -0400 (EDT)

Hi Randy,

I will go along with that and go fight that battle in IPNG. Agreed.
Not all of us implementors have bought into the default-addr-select fyi
who are shipping real IPv6 products.

/jim

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 15 May 2001 12:57:40 -0700 (PDT)

> How do I know to list FE80::2 into the association on the outbound

Let's think about why there are 2 interfaces on the same link in the
first place.  The sys admin wants to have this kind of redundancy
(whether you think it is a good idea or not).  As a matter of fact,
if an OS supports this kind of setup, it may as well allow the sys
admin to specify that there are multiple interfaces in the same link.
This is a manual setup by the sys admin.  The SCTP/IP stack just knows
that FE80::2 and FE80::1 are both on the same link...

As I repeatedly pointed out, we should not have a strict rule set
on address selection unless they are absolutely necessary.  If the
app or system knows what they are doing, they should be allowed to
do so.  So in the above case, if the stack does not know that the
2 interfaces are on the same link, it must not include the other
link local address.

							K. Poon.
							[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 May 2001 23:21:50 +0200 (CEST)

> How do I know to list FE80::2 into the association on the outbound

I suspect that today's IPv6 implementations might not have all the pieces
necessary to do this.
Implementations might only have an interface index, which is different
for each interface, and they need to conceptually maintain a link index
(which is the same for all interfaces attached to the same link but
different for each link) and a site index (with similar properties but
at the site level.

Solaris 8 update 3 might come close to providing a mechanism for the link-local
case (not the site-local case) - the SIOCGLIFGROUPNAME can be used to retrieve
the ascii-string group name for each interface and two interfaces that have
the same non-null group name are attached to the same link. But there isn't a
numeric "link index" hence sin6_scope_id can't capture this at the moment.
Once ipngwg has decided how to encode ifindex, link ids, and site ids in
sin6_scope_id it would make sense to add this to IPv6 implementations.
I don't know if other implementations have similar concepts.

> two to be on the same network right?

See above. Right now implementations may or may not have a mechanism.
But once the encoding is determined you'll start seeing implementations
where sin6_scope_id carries a link id for link-local addresses; today
all implementations I know have a ifindex in sin6_scope_id.

>    an ABORT. aka the black-hole problem..

There is also a small possibility of C) which that there is some other
node which uses fe80::2 and the port numbers and the same verification
tag in which case the misdelivery would cause more unpredictable failures.

So we need to make sure that the sender of the link-local (and site-local)
in the INIT/INIT-ACK know for sure that the included addresses stay within
their scope zone.

   Erik

---

From: Randall Stewart at work <[email-masked]>
Date: Tue, 15 May 2001 17:11:54 -0500

> > But here is the 64,000 Dollar question....
Sorry, but I am a little short of funds right now .. maybe in a 
few years (analysts say it will take 16 years for many stocks to
recover to there peaks :/) 

Besides you have not answered the question.. but I think I have... 

I don't buy admin configuration locally has a method..

> 2 interfaces are on the same link, it must not include the other

The real answer .. as I alluded to in responding to Qiaobing is that
instead I take in do this..

I look In the neighbor list for FE80::2 and see if I can see FE80::1
With
its MAC address. If I Do, I can also cross check in FE80::1 to make sure
I see FE80::2 with its MAC address... 

If I find them in both neighbor caches (with correct mac addresses) then
I
know the two interfaces are on the same physical network.

Now this is VERY VERY grungy and ugly.. since I don't like the idea
of digging through neighbor caches to find out if two of my interfaces
are on the same lan... but it WILL work... on the condition that
I have full access to the neighbor cache to grunge through..

Of course a user land implementation may be at a disadvantage here,
unless
of course some kind soul has put in the kernel access to the neighbor
cache
(sort of like a arp -a for an application :/).

Now with that thought, I think I can live with the Link Local ... I
beleive
Erik had a claus in there about it MUST be on the same network... ..

I will prepare a email with the details and a modified list after I talk
to Steve Deering next week. In the meantime I will get the BIS out
tommorrow
updated without the rules..

After I pow-wow with Steve I will post things to the NG list.

R

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 May 2001 00:41:09 +0200 (CEST)

> know the two interfaces are on the same physical network.

I don't think that follow since you can have:

	Node X			Randy's node			Node Y
	fe80::1 -- link A -- fe80::2     fe80::1 -- link B -- mfe80::2

Thus the fact that you have fe80::1 and fe80::2 as neighbors doesn't mean
that link A and link B is the same link.

I suspect that at least initially it will be reasonable to depend on
an admin configuring the node explicitly when it has two or more interfaces
on the same link.
However, you can construct a very high probability of automatically detecting
such cases when an interface is configured by
	craft a large random number
	send that number in a packet from fe80::1 to fe80::2 (for any pair
	of link local addresses on the node)
	check if the same number arrives on the other interface (the one
	with address fe80::2)
	repeat in reverse direction

But if you assume that the links are stable (i.e. they don't become partitioned
after a while) then you only need to do this when bringing up a new interface
and configuring its link-local address.

  Erik

---

From: Jim Bound <[email-masked]>
Date: Wed, 16 May 2001 06:51:31 -0400 (EDT)

Let me see if I got right what the story is at this point.

If node uses global dst addr in ip hdr for INIT then address parameters
are global, and its src addr in ip hdr is global also.

If node receives INIT at one of its global addrs (meaning the address
parameters are global) then  it can send INIT-ACT with site-local
src addr and its address parameters as site-local if it so desires, and of
course is responding to global dst addr where the INIT came from.

But in the above case neither can use link-local as address parameters.

If node sends INIT with dst addr in ip hdr is site-local then it can have
addr parameters that are site-local or global, but its src addr in ip hdr
can be site-local or global.

Node responding to INIT with INIT-ACK can respond with site-local or
global.

But again in the above case neither can use link-local.

Lastly there is no case where link-locals are recommended to be used as
address parameters.

But this won't be in 2960bis and in some other document..

And this work should be done in the IPv6 working group.

It is unkown if this other document is standards tracked or not.

Is this the consenus of the working group?

regards,
/jim