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

From: Jonathan Wood <[email-masked]>
Date: Thu, 10 May 2001 14:35:13 -0700 (PDT)

>
>Jonathan Wood wrote:
>> 
>> I agree with rules A1-A3, and B1-B3, but not the rest for
>> the reasons stated in my previous email ("this is not the
>> place to solve this problem").
>> 
>> However, I would agree if we changed the MUSTs to SHOULDs
>> in A4-A6 and B4-B5. (What happened to A5, BTW?)
>> 
>Opps... A6) is a typo and should be A5 :/
>
>Now as far as A4-A6 and B4-B5... Please to tell me how you will
>prevent losing the association?

You only lose the association in the scenario you described below.
This scenario is not guaranteed to happen. Granted the results
are not productive, which is why I agree that we should not
send site locals by default.

However, there are many other scenarios where this will not happen,
and it will be OK to send site-locals. In these situations, the site
administrator can explicitly tell the SCTP stack that it is OK
to send site locals, and everything works as expected. This is really
a policy /  configuration choice, not something we need to enforce
in the protocol.

That's why I recommend changing the MUSTs to SHOULDs in A/B 4-5.
This allows the protocol to flexible and useful in a variety
of scenarios, while still make a a strong recommendation for
a sane default behavior.

j

>
>Someone, somewhere on two different sites (aka cisco and sun) will set
>a host to siteaddress FECO::0001 one of them being a machine I send
>an INIT to destined for a global address...
>
>and then when I send you a INIT, you will send me the INIT-ACK with
>FECO::0001
>inside it (with out rule B4). Then of course I will send a HB to 
>FEC0::0001, not knowing that you are not on my site... (unless Jim
>has a way for me to tell.. I don't know it... Jim??) 
>
>When the local machine configured to FEC0::0001 gets the HB, of course
>being
>a SCTP capable machine, it will send back an OOTB abort and thus
>our association will go in the dumper...
>
>
>How can you avoid this may I ask?
>
>Either you or Jim need to tell me this before I would be willing
>to agree with you..
>
>R
>
>> Jonathan
>> 
>> >
>> >Now here are the basic rules I have devised for the BIS ..
>> >****Jim please take a close look at these and either
>> >educate me or critic them :/
>> >
>> > "
>> > 5.1.2.1 Special rules for IPv6 address scoping
>> >
>> >     When selecting IPv6 addresses to include as parameters in the INIT
>> >     chunk the following rules MUST be applied:
>> >
>> >     A1) The INIT chunk MUST NOT include any IPv6 Link Local
>> >         address parameters.
>> >
>> >     A2) An IPv6 Link Local address MAY be used has a destination
>> >         address for an SCTP packet containing an INIT chunk.
>> >
>> >     A3) If the destination address of the INIT is a Site-Local or
>> >         Link Local address, then both Site-Local and Global IPv6
>> >         address parameters SHOULD be included in the INIT chunk.
>> >
>> >     A4) If the destination address of the INIT is an IPv6 Global
>> >         address then the sender MUST NOT include any Site-Local
>> >         IPv6 address parameters in the INIT chunk.
>> >
>> >     A6) If the destination address of the INIT is an IPv4 Address
>> >         then the sender MUST NOT include any Site-Local IPV6
>> >         address parameters in the INIT chunk.
>> >
>> >     When responding to an INIT chunk and selecting IPv6 address
>> >     parameters to be included in the INIT-ACK chunk, the following
>> >rules
>> >     MUST be applied:
>> >
>> >     B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local
>> >         address parameters.
>> >
>> >     B2) If the source address of the SCTP packet containing the INIT
>> >         chunk is a IPv6 Link-Local address, then both Site-Local and
>> >         Global IPv6 address parameters SHOULD be included in the
>> >         INIT-ACK chunk.
>> >
>> >     B3) If the source address of the SCTP packet containing the INIT
>> >         chunk is an IPv6 Site-Local address, then both Site-Local
>> >         and Global IPv6 address parameters SHOULD be included in
>> >         the INIT-ACK chunk.
>> >
>> >     B4) If the source address of the SCTP packet containing the INIT
>> >         chunk is an IPv6 Global address, then the sender MUST NOT
>> >         include any Site-Local IPv6 address parameters in the
>> >         INIT-ACK chunk.
>> >
>> >     B5) If the source address of the SCTP packet containing the INIT
>> >         chunk is an IPv4 address, then the sender MUST NOT
>> >         include any Site-Local IPv6 address parameters in the
>> >         INIT-ACK chunk.
>> >
>> > "
>> >
>> >--
>> >Randall R. Stewart
>> >Systems & Solutions Engineering
>> >Cisco Systems Inc.
>> >[email-masked] 815-342-5222 or 815-477-2127
>> >
>> >
>> >
>> >---
>> >You are currently subscribed to sigtran as: [email-masked]
>> >To unsubscribe send a blank email to
>> [email-masked]
>
>-- 
>Randall R. Stewart
>Systems & Solutions Engineering
>Cisco Systems Inc.
>[email-masked] 815-342-5222 or 815-477-2127
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 10 May 2001 20:44:14 -0500

> send site locals by default.

Considering how long IPv6 addresses are AND the fact that you can
set them.. site local addresses will be prime candidates for ::0001
and ::0002.. That being the case this "scenario" will be VERY VERY
common.  I cannot see adding a case where one can create a "blackhole"
that
will knock down SCTP associtations. This is a very very bad design
element to put in a transport protocol.

For those that want to ADD site-local addresses, I think the ADD-IP
feature could be used. 

> a policy /  configuration choice, not something we need to enforce

I just think it is bad to make it so that you have a very very big
potential to commonly lose associations.. which is what you are
putting in place..

> of scenarios, while still make a a strong recommendation for

And they can get back that flexibilty by using the Add-Ip feature
to add back the additional site-locals...

I still stand un-convinced..

Vern, I am adding you to this thread.. what do you think... I remember
us talking about "black-hole" tcp situations and how it is 
important to avoid them??? comments please??

Steve, when you return please put your 2 cents in .. 

Jim Bound I would like your comments as well ...

R

---

From: Jim Bound <[email-masked]>
Date: Thu, 10 May 2001 23:35:04 -0400 (EDT)

Randy,

I think A thru B are fine as you wrote them.  I believe all we need is
Global and Link-Local for IPv6.  But I lost that battle.  One thing that
makes me work on them in my work is exactly what you said.  They will be
used and are part of IPv6.  Also they will be useful for site-only
communications where it is administratively defined.  But.....I strongly
believe in putting major controls on them where interoperability can be
impacted such as a black-hole.  That we have a responsibility to prevent
and it not setting policy but using an abstraction as best we can today.
Thus I support your MUSTs.  They put some control on the options.  

Also as far as Multihoming.  A node can be Multihomed on the same link
with 

Node A - Link1
  interfaceA1 scope=link-local MAC == MA1
  interfaceA2 scope=link-local MAC == MA2

Node B - Link1

  interfaceB1 scope=link-local MAC == MB1
  interfaceB2 scope=link-local MAC == MB2

As you pointed out for link-local the sin6_scope_ID must be an Interface.

Smart implementations keep that interface with the datastructure that
holds the link-local address or anywhere its used.  Because....

Node A - Link2
  interfaceA1 scope=link-local MAC == MA1

Is permissable for Link 2. So an app sending to FE80::MA1 either needs to
specify the interface via sin6_scope_ID or let the default happen and that
would be based on the implementation or should be a configured user
interface which no one I know does today.

For site-local the sin6_scope_ID becomes a site or zone identifier.

But for Node A to know that if link1 goes down it can use link2 would
mean something has told Node A that is possible.  That does not exist in
IPv6 today other than by hackery of a unified neighor cache.  Multi6 WG is
working on this now yes.

One proposed idea is to use SCTP to solve the problem :----) But I don't
believe anyone has suggested using them for link-locals.  But for globals
for multihoming to an ISP and whats interesting is if site-locals are used
per this conversation.

/jim

---

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

Jim,

> Thus I support your MUSTs.  They put some control on the options.  

Correct me if I am wrong in interpreting you.  Putting a MUST in a
protocol spec is not the same as putting controls on how people should
use some features.  As a matter of fact, if an app knows perfectly
what it is doing (using site-local addresses), I don't see why the
protocol itself should force it to do otherwise.  Having a MUST in
the spec ensures that the protocol stack should reject such request.
It is not just a tunable.

Note the difference between this and say congestion control.  Congestion
control has to be enforced because it affects other traffic.  If an
app screws up and gets into a black hole situation because it picks the
wrong addresses, it is the app's problem.  And if an implementation
screws up and selects the wrong addresses when the app does not specify
anything, it is the implementation's problem.

As I mentioned before, address selection is also a policy issue.  And
I really doubt that we should enforce a policy on how people should
use SCTP.  If an administrator uses the wrong policy and screws up SCTP
traffic, it is the administrator's problem.  This is not a protocol issue.
It is an implementation issue and administrative issue.

							K. Poon.
							[email-masked]

---

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

> For those that want to ADD site-local addresses, I think the ADD-IP

We are talking about the basic SCTP standard spec here.  We should not
say that something can be fixed by some option so that something can
be put in the spec.  As I mentioned many times, there are cases when
selecting site local addresses are wrong but there are also case when
they are perfectly fine.  I really don't see the reason why a standard
spec should disallow those perfectly legal cases.  We are talking about
standard spec, not best of practise.

> potential to commonly lose associations.. which is what you are

If something goes wrong, it is the app/implementation/administrator's
problem, not a problem in the SCTP spec.  The case is similar to the
following requirement on TCP.  If TCP gets a RST to destination A,
TCP MUST not conenct to A again for, say, 60s.  This may make sense
for some situations/apps.  But to put in the standard spec is a
different issue.

							K. Poon.
							[email-masked]

---

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

> anything, it is the implementation's problem.
Here is where your logic falls apart completely...

1) Administrator at site A configures site local addresses FEC0::01 - 5
2) Administrator at site B configures site local addresses FEC0::01 - 5
3) Application sends a INIT from A to be to the global address... the
   only one it can send to... it lists its site local because this is
   the rules that apply.. there is no restriction NOT TO
4) The association comes up and every one is happy.;
5) The endpoint at site B send a HB to the site local address.
6) It gets an abort from the local machine.
7) The next message endpoint at site A sends generates an abort.

Now HOW did the application pick the wrong address? It used the
only address it could, the global... Even worse.. it may work
fine for hours until the salesmen that has the machine that sends
the first abort wanders back in and plugs in his machine and turns
it on... Very VERY hard to trace... and a nightmare..

Having a consistent set of rules as to when you send the site local
addresses will prevent this behavior..

I would in turn, turn your argument on you... if you really wish
to use site local and ARE on the same site.. then it is an application
address error to send an INIT to the global address of the peer. Instead
it should correct its address it is sending to and use the site-local
address of the peer... THIS is truely an application problem for
NOT using its sitelocal address when it should have!!

R

---

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

> standard spec, not best of practise.

And to use your reasoning.. this is an administrative problem then .. if
you use a global addres and you SHOULD have used a site local address
your application made an error in sending an INTI to the wrong address.

> for some situations/apps.  But to put in the standard spec is a

There is a big difference in getting a RST and breaking the protocol
so that you get a black hole condition.. sorry I am unconvinced..

Maybe you could convince me by sharing with me how you think
it is valid to send a site local in an address list when sending
to a global address... I don't see what it can possibly gain you..
Site local addresses by the definition in IPV6 are not supposed to
go out of the site.. you want to create hole in the protocol where
they CAN go out of the site..

Sorry I disagree..

R

---

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

> Here is where your logic falls apart completely...

I guess you still mis-understood my point...   But let's look
at your example below first.

>    the rules that apply.. there is no restriction NOT TO

Are you suggesting that the policy says that it MUST include the
site local address?  I don't think anyone will create such policy.
And to say that there is no policy requiring that it should not means
automatically it has to is wrong.  This is like saying that the law
does not prohibit people from writing buggy code automatically means
that people will always write buggy code!

As I repeatedly stress that I am not saying that the rule set you
proposed is wrong.  And I am defintely not saying that the example you
sited is wrong.  I am stressing that we should not put it in the standard
spec.

> it on... Very VERY hard to trace... and a nightmare..

Now look at how a reasonable (not using your logic that it has to
do the wrong thing if not prohibited) app will work.  It looks up
a machine X in site B and gets back only the global address.  A's
DNS policy is that if a site is in A's site, both global and site
local addresses will be returned.  By getting only the global address,
the app automatically knows that X is not in the same site as A.
So it simply will not add its own site local addresses to the 
address list.  And A's SCTP policy can be that if an app does not
specifically add site local addresses, SCTP stack should not include
any site local address in the address list.  Everything will work
out just fine.  This is just an example of how things can work.

> addresses will prevent this behavior..

Once again, I am not against your set of rules.  I am saying that to
put such set of rules in a standard spec is not a good choice because
it simply prohibits some other reasonable policies.  There can be
many many other reasonable policies.  Your rule set can perfectly
be one of them.

> NOT using its sitelocal address when it should have!!

This is fine with me.  What is the problem here?  If the policy
is such that the app is doing the wrong thing, so be it.  The app
screws up.  It is an application problem.

							K. Poon.
							[email-masked]

---

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

> they CAN go out of the site..

I guess we need to settle one thing.  I have never said that the
problems you sited do not exist.  I am saying that there are other
situations that it can work.  That's all I have been trying to point
out.  And because of that, I don't think it is a good choice to put
a strict rule set in the standard spec.

As I have mentioned in a previous mail, it may be just that the
app is quite stupid and just uses the first entry from a DNS query
as the destination address.  But it is not that stupid to make
sure that there are also site local addresses returned so that it
knows the remote site is in the same site and it can include
its own site local addresses.  This is just a stupid example.  But
it works.  And that's all I want to point out...

							K. Poon.
							[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Sat, 12 May 2001 00:08:22 -0400 (EDT)

Hi Kacheong,

> It is not just a tunable.

What you say is usually correct and I agree with you.  But this case I
think is different.  The only way to know if there is site-to-site
communications (ignoring admins can administer it which is not good to do
after this discussion I am almost totally convinced) is if the two peers
actually communicate using a site-local address in the IP Header src/dst
fields.  Then you know for sure that you have site-to-site connectivity.
Otherwise you simply do not know.

The reason I support the MUST in this case is because I do not believe
that hearing errors via Heartbeats or other mechanisms should be a tool to
see if site-locals could be used.  We would then be saying proper protocol
design is to use it tell me it won't work.  Then with SCTP you know have a
complete association that has a mess in the worst case.

Lets take an intense case.

I am a squad leader in an army platoon using my laptop for communications
back to my command post in a combat situation.  I use a global address in
the IP src/dst packet for an init using SCTP.  But I put site-locals in
the params for all my addresses. Then communications begins and one of the
peers trys to use the site-local and it don't work, not because of a
network problem but because it WOULD HAVE NEVER WORKED.  Ouch. The results
of this failed communciations like others could catastrphoic to the Squad.

Or take a robot at a GM plant floor getting engineering mcad data to do
real time drilling of keyholes into the door behind the upholstrey.  It
depnends on some timer from a peer for robotic control.  The admin
switches the sites around and the robot drills a hole through the key hole
and rips the upholstrey.

Both are cases where the pain from permitting this in the protocol I think
is really not wise.  Its not just a blackhole.  But the effect from the
blackhole and the resultant error and effect.  I think when we develop a
protocol where the essential behavior of it causes a direct error by
heuristics we need to be very conservative.  That is why a MUST is good in
this case.  
 
> anything, it is the implementation's problem.

Congestion control depends on far more variables than just a peer to peer
correct behavior.  It involves all entities within the path of the packet.

Also we know a priori that this won't work with site-local that is not the
case in the congestion axiom.  That axiom is totally dependent on user or
some selection or policy.  SCTP is a transport protocol and the state
machine for the engine IP to work.  Congestion and such are not in the
same league in my mind as what is and what is not permissable.  If
congestion fails recovery is probable.  But sending a packet to a
site-local that is not in the nodes site is not wise or the same. 

 > As I mentioned before, address selection is also a policy issue.
And > I really doubt that we should enforce a policy on how people should
> It is an implementation issue and administrative issue.

Hey on address seletion your preaching to the choir I agree with you 100%.

But that is not what is happening here.  Whats happening is Randy is
trying to prevent an error condiditon in the protocol not address
selection.  Address selection is not in my view even within the logic
table for the MUST vs SHOULD decision.  

I just think its not wise or common sense to permit a transport protocol
operate on the criteria that it will recover from something that can be
prevented by Randy's taxonomy to resolve this.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Sat, 12 May 2001 00:22:01 -0400 (EDT)

just a nit.  sitelocals being in DNS are still TBD.  And multisited DNS
servers for IPv6 have no existing practice.  

/jim

On Fri, 11 May 2001, Kacheong Poon wrote:

> many many other reasonable policies..  Your rule set can perfectly
> be one of them.
>

---

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

Jim:

Just a quick comment...

> table for the MUST vs SHOULD decision.

This is something I forgot to say.. the table does NOT say what
of all of your addresses you select.. .you can only send part of
your global addresses... it is exactly has you say Jim... only to
prevent this horid error...

R

---

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

> out just fine.  This is just an example of how things can work.

Where in the world is the kernel going to get DNS policy from?
Are you suggesting to go back and do the hostname query... no
one is implementing this has it is... since it is very
difficult to do the kernel upcall?  I don't think you can count
on the kernel having DNS policy.. or being able to know the site/global
addresses...

Besides the above "reasonable example" you state above is exactly
what you would get if you followed the rule set..

> many many other reasonable policies.  Your rule set can perfectly

And here is where we are at a complete impasse..

Explain to me a reasonable policy that does not use the rule set:

A) link local addresses are only valid on the local link.
B) Site local addresses are only valid in the site
C) Global addresses are always valid..

Now show me where the rules laid out violate any of the above and
even more so show me where you can do anything that does not
follow the rules that is valid...

The ONLY thing I can think of is the idea that someone may
have a interface with just a site local, and a second interface
with a global and a site local.. by following the rules in
this case that I laid out you could get a INIT sent to the global
and the two endpoints would lose the multi-homing... Jim said that
this was a very very unlikely scenario.. but lets just pretend for
a moment that it could be out there..

1) nothing breaks as far as the protocol
2) I can use your earlier argument and state that this
   is a configuration error on the part of the application/adminstrator
   and they should have used the site-local so they can get the
   redundancy.

Now, besides this case, please show me where following the rules in
the BIS will stop you from doing something? Please don't give me
vague references to the future... tell me what it prevents ...

The only way I can see it preventing something is if we start to
change the very definitions of what a site-local is.. if we do
this then we have a protocol specification changing and I think
we could very well be expected to change SCTP...

Now, I have thought on your earlier link-local example.. its what
kept me from going to sleep :/  

It is invalid in that you will once again create a black hole scenario.
Besides the fact that it can only work if you configure your machine
in a particular way..

Again.. you send an INIT A->B with 2 link-local's one is the
destination.

problems with this are

1) You don't know that B is connected to both link-locals, so 
   its possible if he has another interface it leads out to a
   different link where you will get an abort back.

2) Even if  you are on the same links, since B may have 3 or more
interfaces
   it still may well not be able to tell which scope it belongs with.

3) You can only make your kludge work on your side if you only allow
   for two networks (if you have three you are dead) AND you only
   send one link local for each interface... there may exist more than
   one...

So, again .. the rules in the bis keep you from doing something very
bad..

R

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 May 2001 13:18:33 -0700 (PDT)

I think we are just disagreeing on one little point, whether to
put it in the standard spec.  Before replying your mail below,
let's just look at a v4 example and see if you think it should
also be put in the standard spec.  A machine has two interfaces,
one has a global v4 address and the other has a private v4 address
(RFC 1918).  I guess when talking outside its own network with
SCTP, the private v4 address should not be listed, right?

But the problem here is within the network, the private v4
address works perfectly fine.  And this actually provides more
reliability to the app within the organization.  So are you
suggesting we should also put this in the spec to prevent such
practise?

> on the kernel having DNS policy.. or being able to know the site/global

I know you'd like to reply quickly always (-:  But please do read
the original mail carefully.  It is the app which gets the DNS reply,
not the kernel.  The kernel has nothing to do with DNS query, no
upcall at all...  I am one of those who strongly disagree on the
hostname address param...

> what you would get if you followed the rule set..

Actually, it is not the same.  The reason why you think it is the same
is that the app does not include the site local in the list.  Note that an
app can also control what to list in the address param list, not just

> C) Global addresses are always valid..

The above are by definition true.

> follow the rules that is valid...

As I pointed out repeatedly, I never said that your rule set was
wrong.  I just don't want to have such a strict rule set in the 
standard spec at this point of time.  And I just tried to come up
with some examples to illustrate my point that there can be valid
exception to your rule set.

> vague references to the future... tell me what it prevents ...

I think I have talked about several examples before, don't want to
repeat them here.  Please go thru the emails slowly and see if you
agree.

>    different link where you will get an abort back.

It seems that this is our major disagreement on this little issue.
To me, the app screws up because it knows that it adds a link local
address from a different link when it sends out the INIT.  What
I tried to say is if the app knows that it is doing the right thing,
what is the problem with that?  It will work.

>    it still may well not be able to tell which scope it belongs with.

My stupid assumption on this example is that B should treat all the
link local addresses list to be on the same incoming link.  Note that
I am not saying this is a good practise.  It is probably not normally.
You know what I am trying to say...

>    send one link local for each interface... there may exist more than

I think we are thinking about 2 different scenarioes.  Mine is the
stupid one with multiple interfaces on the same link, yours is a more
complicated one.  And you are right that my stupid method will not
work in other setups.  But this is not the point I am trying to make...

I think we are already beating a dead horse here.  Could the chairs advise
us how we should proceed?  It seems that the only disagreement we have
is wehther to put the rule set in the bis document.  Shall we take a vote
or use some other methods to probe whether most of use agree or not?

							K. Poon.
							[email-masked]

---

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

Kacheong:

Comments...

> suggesting we should also put this in the spec to prevent such

Hmm, I have thought on this... and yes it might be worth it... but
in the case of v4 we also have NAT's murking up the picture. In the
case you illustrate... most likely if the sender does send outside of
his private address space a big ugly NAT will grab and change his
INIT addresses in at minimum the source address and more likely
it will strip all the TLV's out (yuck.. how ugly).

IPV4 is convoluted by definition since many things are broken with
addressing aka NAT's etc. 

IPV6 is supposed to fix all this... and has Erik said in a
earlier email.. 

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

This does not remove control from the application... If I only bind
a link local address in my SCTP endpoint I will only be able to
talk to peer link-locals.. Same for site-local.. bind only a
site-local and you only talk to peer site-locals... Its when
you bind INADDR_ANY that this whole mess begins to play out. In
this case the user is punting, or for that matter if the user makes
a grevious error... having the rules in places does exactly what
Erik's statement above requests..... they may need to be refined
as Erik as pointed out by using source and destination addresses...

> is wehther to put the rule set in the bis document.  

After much offline conversation.. the rules will move to a different
document.. one the NG group can hopefully spend a bit of time on....
possibly but for sure the addip?..... . Once we get the precise 
wording down, I think it will become a supplement
to SCTP (much like all of the supplements to TCP) until we go
for draft standard.. then I think it will get merged together...maybe :)

R

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 14 May 2001 17:34:41 -0500

Randy,

See my comments below...

Randall Stewart at work wrote:
...snip...
> a grevious error... having the rules in places does exactly what

When arguing against adding some restrictions in SCTP spec to prevent
some potential misuse, someone once said that: "anything powerful can
also hurt you if you do not use it wisely." I think the same wisdom
applies to this scoping issue discussion. 

> for draft standard.. then I think it will get merged together...maybe :)

I fully agree with you... To move the rules into a separate document is
the best solution.

However, in the bis document we do want to warn the SCTP implemetaters
and users and make them fully aware of the pitfalls and potential
dangers of improper use of IPv6 addresses, and advise them to read the
"other document" for the best current guidelines (your rules) on
preventing the problems.

regards,
-Qiaobing

> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 May 2001 15:33:23 -0700 (PDT)

> it will strip all the TLV's out (yuck.. how ugly).

I am not familiar with the latest NAT stuff.  So do they also modify
transport level content now?  The problem we are talking here is in
the address param list.  So the NAT has to understand SCTP and how
to modify the address param list.  Is NAT really doing this kind of
things now, say on the TCP bits?  I know they may reject ECN bits,
but to modify them, I don't know.

> addressing aka NAT's etc. 

Well, even without NAT, we still need to solve the problem.  And
treating private v4 addresses as v6 site local will not work here.

> as Erik as pointed out by using source and destination addresses...

Using your wordings, the app loses its control if it tries to do
what your rules prohibit but may be perfectly legal in a certain setup.
The SCTP stack should fail those special binding when it is forming the
address param list.  That's the reason why I think we should not put
the rule in the bis at this point.

Glad to hear that we seem to have a conclusion on this issue.

							K. Poon.
							[email-masked]

---

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

This is a bad compromise.

Erik is wrong on this.

/jim

On Mon, 14 May 2001, Randall Stewart at work wrote:

> Hmm, I have thought on this... and yes it might be worth it.... but

---

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

right???   are folks still writing code or what?  we are saying we are
going to jump into the transport space or have an extra search on the
common client in the kernel to whack the associations address parameters
because we don't want to adheer to Randys' rule set for the NAT case in
IPv6 where there are plenty of global addresses.  This is plain wrong.
I thought for sure the right thing would be done.  Oh well. Very bogus.

/jim

---

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

> for draft standard.. then I think it will get merged together...maybe :)

I think it would be quite useful for implementors to list the minimal 
constraints on what must not be included as address parameters in the base
spec.

I think this consists of just two rules:
 - if neither the source address nor the destination address is a link
   local address then link local addresses MUST NOT be included in
   the address parameters. Any included link local addresses MUST
   be on the same link as where the packet is sent.
 - (above text with s/link/site/)

The reason it makes sense putting this in the spec is that
without it folks can produce rather broken implementations which can
cause interoperability problems when used in environments where
e.g. site-local addresses are in use. Thus the interoperability problems
might not appear immediately.

  Erik

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 15 May 2001 12:03:01 -0500

Jim and others:

As far as the SCTP bis is concerned, I think we are getting closer to a
conclusion on this issue.

One observation I'd like to make is: for the most part of this
discussion we seem to have overlooked the fact that SCTP is NOT solely a
kernel protocol, and as a matter of fact there exists many user-land
implementations today and they will continue to exist in the future. If
we put restrictions in the base spec to disallow certain behavior or
way-of-use only because it makes little sense or is hard to implement in
the context of a kernel implementation, we may inadvertently harm the
usability of the protocol in a broader scope.

regards,
-Qiaobing

---

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

Qiaobing,

Do you really believe SCTP user space implementation will exist 3 years
from now or the telcos will buy a platform from a vendor who has a user
space SCTP implementation over a kernel based implementation.  A user
space SCTP can never run as fast as a kernel based one.  Unless user space
is defined as the VM370 arch was in the past or possibly MACH 4.0+.

thanks

/jim

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 15 May 2001 13:48:27 -0500

Jim,

Yes, I believe so, for at least two reasons: 1) TCP has been around for
a long time, yet there are still user-space TCP implementations in
existence for various reasons; 2) In some resource-tight operating
environment (e.g., some DSP based small devices), the boundary between
user-land and kernel ceases to exist, and this in effect turns
everything into user-land.

regards,
-Qiaobing

---

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

Qiaobing:

It is for this very reason that I have a large problem
with the Link-Local addresses being included in a INIT/INIT-ACK.
Or should I say opposite reason....

Inside the kernel you COULD use the scope_id in the destination
SCTP packet and then with that scope look in ALL interface neighbor
caches. You would be looking for an appearance of the interface
that the scope_id points to. This would be how you could prove that
two interfaces were hooked to the same physical Lan and thus meet
Erik's restrictions on Link-Local addresses.

If you are up in a application library (like many implementations today)
you
have very limited (if any) access to the neighbor caches of all
interfaces.
Besides which even in the kernel it is a grungy thing to go digging
through
all the neighbor caches.. but it is the only way I know to verify that
several interfaces are on the same network... 

The only other way I can see is NOT to send link-locals in the SCTP
INIT/INIT-ACK
which many user land implementations will have to adopt I think..

R

---

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

> Erik's restrictions on Link-Local addresses.

Doesn't work.
You need to use the yet-to-be invented SIOCGIFLINKID and SIOCGIFSITEID
ioctls to tell what interfaces are attached to the same link and site,
respectively.

Then you just use SIOCGIFADDR to get the link/site local addresses for
the interfaces that are in the same link/site.

So apart from the missing implementation of the above ioctls (or
a functionally similar mechanism) this is quite trivial.

  Erik

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 15 May 2001 18:36:54 -0500

As I explained in my earlier email to Jim, being in user-land also
includes the situation where every thing IS user-land, i.e., no
kernel/userspace separation as one can occasionally see in some
DSP-based small devices.

-Qiaobing

Randall Stewart at work wrote:
> you have very limited (if any) access to the neighbor caches of all interfaces.
> Besides which even in the kernel it is a grungy thing to go digging through
> The only other way I can see is NOT to send link-locals in the SCTP INIT/INIT-ACK