Subject: Re: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)

From: Kacheong Poon <[email-masked]>
Date: Fri, 11 May 2001 18:32:18 -0700 (PDT)

> If you send me an INIT listing a link-local address, say to my IPv4
> address
> (this is the first thing I tried), I then grab out your link local and
> add it to your address list. This is fine.. until I send to it... since
> I have no scope-id I get a unroutable error... Now I know there are
> some stacks that will go digging around in all its neighbor caches
> (at least I have been told this), but this is wrong. So on a correctly
> implemented IPv6 stack, no matter if we are on the same link or not,
> sends
> to addresses listed in the Parmeter list will ALL FAIL. Been there done
> that .. it don't work..

Correct me if I am wrong.  Just assume here for a moment that there are
2 machines A and B, and both have two interfaces on the same link.  The
INIT from A to B uses one of B's link local address as destination and
one of A's link local addresses as source.  A also lists the other link
local address in the address list.  When B gets this INIT, it can 
assume that the link local address in the address list is on the same
link as the source address of INIT (same scope id).  So you won't run
into the problem you mentioned.

Note that I am not suggesting how things should work here.  Different
implementations can do different things.  And in some implementations
this may not be possible.  And I am not saying this is the correct
way to implement SCTP, it may possibly be the most stupid way (-:  I
merely want to point out that as long as something can work, and does
not do any harm, we should not prohibit it in the standard spec.

							K. Poon.
							[email-masked]

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

---

From: Randall Stewart at work <[email-masked]>
Date: Fri, 11 May 2001 21:29:56 -0500

> into the problem you mentioned.

Huh? I don't think I buy this at all...if the link local is listed you
have NO idea which scope it belongs to. The only one you can tell
for sure is where it came from.. now if I am in a very simple case
of just two network cards  and two and only two addresses.. but consider
my
ifconfg:

an0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.1.3.1 netmask 0xffffff00 broadcast 10.1.3.255
        inet6 fe80::240:96ff:fe49:b753%an0 prefixlen 64 scopeid 0x1 
        ether 00:40:96:49:b7:53 
sis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.1.2.3 netmask 0xffffff00 broadcast 10.1.2.255
        inet6 fe80::2a0:ccff:fe7c:86eb%sis0 prefixlen 64 scopeid 0x2 
        inet6 3ffe:507:187:3:2a0:ccff:fe7c:86eb prefixlen 64 
        ether 00:a0:cc:7c:86:eb 
        media: autoselect (100baseTX <full-duplex>) status: active
        supported media: autoselect 100baseTX <full-duplex> 100baseTX
10baseT/UTP <full-duplex> 10baseT/UTP none
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.1.1.3 netmask 0xffffff00 broadcast 10.1.1.255
        inet6 fe80::2c0:4fff:fe8f:3dfb%xl0 prefixlen 64 scopeid 0x3 
        inet6 3ffe:507:187:2:2c0:4fff:fe8f:3dfb prefixlen 64 
        ether 00:c0:4f:8f:3d:fb 
             supported media: autoselect 100baseTX <full-duplex>
100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
faith0: flags=8000<MULTICAST> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0xa 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::240:96ff:fe49:b753%tun0 --> :: prefixlen 64 scopeid
0xd 
        inet 10.83.97.69 --> 10.83.97.1 netmask 0xff000000 
        Opened by PID 23337
   media: autoselect (100baseTX <full-duplex>) status: active

And I don't have more than one Link Local.. which I have seen in
other machines.. a link local with the mac AND a link local
with something more friendly like
fe80::1

etc...

So your simple algorithm will quickly break down in all
but the very simplist of lucky cases...

I don't believe you can depend on this.. and besides I am not
convinced it will work..

R

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

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 11 May 2001 20:11:49 -0700 (PDT)

Oops, you just told everyone in the world your network setup...  Hmm,

> of just two network cards  and two and only two addresses.. but consider

< Network setup deleted... >

> I don't believe you can depend on this.. and besides I am not

Please note that we are talking about two different setups here.
So in some cases in your particular setup, link local address should
not be used.  That's OK.  But in the stupid setup I mentioned, it
will work (correct me if I am wrong).  Why should we prohibit such
setup in the standard spec?  Just leave it to the implementation to
deal with it.

							K. Poon.
							[email-masked]

---

From: Randall Stewart at work <[email-masked]>
Date: Sat, 12 May 2001 01:09:41 -0500

> be careful of some hacker (-:

Good luck reaching my lan.. 10.1.1.3 is hard to get too :-)
and my DSL has been down for over a month :-/

> setup in the standard spec?  Just leave it to the implementation to
And my earlier email tells you why it won't work...

R