Subject: Re: [Tsvwg] RFC2960bis ... heads up Steve

From: Randall Stewart <[email-masked]>
Date: Thu, 10 May 2001 07:09:03 -0500

Jim Bound wrote:
> 
> Hi Randy,
> 
> Comments enclosed.
> 
> This was forwarded to me and not on this list for now as I trust
> you:---)....
> 

thanks Jim... some comments below..

> > [email-masked] wrote:
> >
> > >
> > > > 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:
> >
> > 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.
> 
> We should permit link-local addresses just like we do for TCP.  Each
> link-local and site-local will have a sin6_scope_ID or identifier.
> Both ends of the SCTP connection will have an identifier for the
> link-local address.  In IPv6 the base API permits one to identify the
> interface based on the scope and identifier.  With this why should not
> link-locals be permitted by SCTP?
> 
> But an implementation of IPv6 would have to support the idea of scoping
> within their IP kernel stack.  Most do not today that are product but all
> had to deal with this to get it to work.
> 

Yes, the implementations at the bakeoff permitted scoping via the
sin6_scope_ID.
The trick here I refer to is that yes, you can let the sender issue a
INIT
to a link local (by letting the sender specifiy the sin6_scope_id
field)... this
is how the ref-implementation works. However the sender of the INIT can
never
put the site-local address listed inside the INIT in a parameter. The
reason
being when I recieve a packet from a site local (i.e. the INIT) I get
the
from address filled in with the sin6_scope_id. However if a link_local
address
was listed in the INIT list, then I (the receiver of the INIT) would
have no
way to tell which interface the site-local went to... since the peer has
no way of knowing which interface and scope_id my local stack as
assigned.

The only way site-local for SCTP makes since is has a source or
destination address.

In the above case, I am forced by the MUST in RFC2960 to reply to the
address
that sent me the INIT. This means my peers site-local.... This way the
peer
will get my site-local with proper scope and everything works... it is
just
we MUST NOT list site-local addresses in the address list inside the
INIT or INIT-ACK.

> > 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.
> 
> This is the correct behavior but it really should be up to each
> implementation but this is the default I would have implemented.
> 
> > or
> >
> > B) Always send your Site-Local and Global addresses to a peer.
> 
> This is a waste and the risk of the other peers site-local
> not being in your site will be very high for the first real uses of
> SCTP.
> >
> > 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.
> 
> This is the correct response.
> 
> > or
> >
> > 2) Always send your site-Local and Global addresses in the INIT-ACK.
> 
> Same response as to B.
> 
> >
> > 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..
> 
> Also site-local dst addresses will not be permitted to leave the site
> they are located in by the Ipv6 Routers is current thinking.
> 

Yes, this is exactly why we should NOT list site-local in a INIT or
INIT-ACK
unless we know that the peer is on our same site.. 

And the only way I can think of to do this is to receiver a INIT from a
peer
in the from address. Then I can be assured that the peer is at my
site...
Unless there is another way to do this that I don't know???

> > 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...
> 
> I don't see why you think we have a redundant network.
> 
> A rule that might be good is don't accept site-local addresses that
> are not in your site in SCTP as SCTP peer!!!!
> 

But how do you tell this, only way I know is by the from address... if
the
peer lists site-local inside the INIT I have no way to know if he
is on the same site UNLESS the source address is also site-local.

My point on redundant networks is this... 

  Host A                                                         Host B

------------+                                                
+-------------
            |                                                 |
            +---- Site Local Only-----------------------------+
            |                                                 |
            |                                                 |
            +---- Global and Site local Address---------------+
            |                                                 |
------------+                                                
+---------------

Now in the above, depending on where I send the INIT to determines if
I get site local addresses included.

  - If I send the INIT from HOST-A to the global address of HOST-B,
    then I should NOT list any site local... since I can not be assured 
    that the peer is on the same site. This means the upper network
    will not be in the association.

  - If I send the INIT to one of HOST-B's site-local, then I list all
    my site local.. since we are on the same site.

  - If I send the INIT to say one of the link local addresses of HOST-B,
then
    I would list Site-local and Global (but not link-local) inside the
INIT
    and the single link-local WOULD be included in the association via
the
    rule that the from address is always implicitly included and HOST-B
would
    recieve the link-local address in the from address with the proper
scope.

> > 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..
> 
> I think you did write the right code.  And doing B/2 worked only because
> a longer list was able to be checked.
> 
> SCTP should determine how to make A/1 work and your gut instinct was
> correct.
> 
Great... I was hoping so.. but IPv6 was new to me even though I
had read Christian H's book...

> But make sure the problem is that of not understanding scoping in IPv6
> within an IPv6 context.  I think you should solve this here in the
> transport area and the IPv6 experts should come to you.  You could get
> more than you asked for throwing this over the wall to another group
> who does not understand SCTP at this point in time till its more
> pervasive in our community out of the transport area.  I am here as
> needed and I am sure Steve and others are too.  The ADs in this case
> are intimately familiar with IPv6 too.  IPng and Multihome groups are
> very good like this one but they are pretty maxed right now too.
> My 2 cents on that idea.
> 

Thanks jim, I trust you as well and I will put into the BIS (I have not
released it yet) rules for A/1 above...

R

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

---

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

Hi Randy,

Always a pleasure to converse with you. I wish all authors/tech leaders in
our community could do what you do lead, implement, and deal with all the
mail and questions in such a timely fashion.  Including me..........  Also
at our IPv6 Ottawa Summit in Canada Summit next week I will say in my own
individual opinion SCTP is required for wide IPv6 deployment because of
many reasons but three specifically IPv6 Multihoming, 3G deployment, and
Media Gateways for Telco VoIP parts (but don't become a bell head :--)) 
My comments will be from a deployment perspective not commenting on the
ability or fruition of IETF work.

> The only way site-local for SCTP makes since is has a source or

If the parameter address for the INIT is ipv6.  And the interface the
packet was recorded in in6_ifnet index.  Then the implementation would
know what site the packet came in on and the link. The magic here is to
make that available to the sctp_pcb or whatever one wants to define it as
in their IP implementation in the kernel (I will be doing AD with freebsd
and will put your sctp imp on the machine once I get better organized to
test out other v6 stuff so I will see the source soon) most likely as
pointer to that datastructure in the sctppcb.

Then I could look at any site-local from INIT and know if it was in my
site and attach a site-index to that address in the sctppcb.  Likewise
with a link-local address.

Why would that not work? thanks.

If its not in my site I don't believe we should accept that site-local
address in INIT? 

> we MUST NOT list site-local addresses in the address list inside the

Could we not tell the sender in the INIT-ACK lets not use this site-local
as we are in different sites?

> Unless there is another way to do this that I don't know???

I suggested another way above but its a lot of messing around I agree.
But FOR SURE we don't want to go to USER SPACE to find out (e.g. DNS,
Resolver Caches) that is brain dead and will hurt SCTP performance on
Association startup.  I would rather see us just not send site-locals in
the parameters if that is our only option.  Also so mobile terminals don't
have to do such things either.

Sending link-locals MUST NOT be done though.  I think we all agree on that
right.  As IPv6 address parameters to be clear.  Right?

I am not a fan of site-locals but they are here and we have to deal with
them.

> is on the same site UNLESS the source address is also site-local.

If a parameter is FEC0::234::MAC1 234 is the site-id or just look at
high-order 64bits and if they match the site-id on the link the INIT came
in on I can tell if there is match.

But implementations as I said that have product have not done this but I
think MS research folks have something here and maybe Francis Dupont and
KAME folks.

We all need to put this in IPv6 next releases for sure.

>     my site local... since we are on the same site.
> 

OH OK. So someone has administratively declared a site-local only link.
Hmmm that sounds like bad planning and bad idea. Globals should work on
any link in IPv6.  So I question if the site-local-only link is reality
and in fact would think that with the sctp benefit of failover that if the
global/site-link goes down then globals are by definition permitted over
the site-local only link.

So I would declare a link that is site-local only is impossible with IPv6
to enforce except by doing a config ruleset at the router to filter them.
And that I think is a very bad thing to do.
Because how does one tell the end systems this has been done? That would
require an extenion to neighbor discovery off the top of my head. Thats
crazy to support for correct IPv6 protocol operation IMO.

But I do think two sctp peers can know if a site-local address is in fact
within their site at both ends.

Also sorry I forgot the implicit assumption of using the address to send
the INIT implies its part of the association.  But I think that is the
only valid case of link local that should be supported for correct
protocol operation as the errors that could cause in parameters could be
quite daunting.  But I do know those in the IPv6 community that would
argue permitting it because one could keep neighbor advertisements to know
if a link-local is in fact on the link at the INIT but that code would not
be cohesive to the sctp peer receiving the INIT as would be checking for
the site-local address is in fact valid in a parameter and would
performance implications for sure site-local code execution would not.

> had read Christian H's book...

This in IMO is the best one.  But needs revision and we figured out
scoping after the publishing date of this book :----)

> released it yet) rules for A/1 above...

But as I said if you had a bakeoff now and tried to do in the code what I
state with scoping it most likely will not be there yet.  I don't think
it is fair to expect our SCTP folks to add this code to IPv6 so this is a
wake up call to me and I hope others we need to get scoping like pronto in
our IPv6 base.  Also it will be too spread out over the stack to do it as
patch to current shipping products so I think this raises the bar and
priority of doing scoping in our IPv6 stacks and APIs and will do my best
to rally my colleagues building IPv6 stacks of this urgency.

Of course want to hear if my ideas above are worth it or whacked as I
don't claim to understand SCTP as well as others on this list, but I hope
to be a user of SCTP though and use it to implement network functions
like multihoming on IPv6 stack.

thanks Randy,
/jim

---

From: Randall Stewart <[email-masked]>
Date: Thu, 10 May 2001 12:31:43 -0500

Jim:

I think some of this is my fundamental ignorance... or misunderstanding so
maybe you can educate me a bit here :)

> Why would that not work? thanks.

I am missing something here... I am not sure what a in6_ifnet index is.. I know
what a sin6_scope_id is.. but not this other one. So this may be my problem....

Now when I send an INIT, IF I put a site local address in I simply put

Parameter = IpV6 (0x0006)
Parm Length = 20
Value = 128bit IPv6 Address

Now my problem is the same one I have for link local... if I have a
site local, and my application instructs me to send this to
a peers IPv6 global address... how do I know to list a
site-local address in my parameter list. If I do, there is a
good change the peer is NOT on my site...

Now if I am sending to a site-local there is no problem since then
I know the peer is ON my site OR the INIT will fail...

The same thing applies for receiving a Site-Local address in a INIT list.
If I see the source address of the packet IS a site-local, then my peer
and I MUST be on the same site... but if instead the packet containing the INIT
is sourced
from some other address say even a IPv4 address, How do I tell if a IPv6 site
local
address listed as illustrated above is on my same site. The peer will have no
idea
either... the only sure way that I can see is that the INIT is sent to a site
local and
the peer receives the packet FROM a site local...

What am I missing??

> If its not in my site I don't believe we should accept that site-local

But this is my confusion.. if I compose an INIT how do I know if
you are in my site or not based on the application sending to a
Global address... I have no way that I know of... please educate me here...

> as we are in different sites?

I think you do this by NOT inculding the site local in the address list..

> I suggested another way above but its a lot of messing around I agree.

I guess I don't understand this method... how can I tell when I am about
to send an INIT to a IPv6 global address if the peer is on my site?
This is my fundamental question...

> in on I can tell if there is match.

I am missing something or we are in violent agreement :)

If the source address of the IPv6 packet is a site-local there3 is NO problem ...
we
MUST be on the same site.. and we are happy..

But if the source address is an IPv6 Global address... If the sender lists
a site local address say

FEC0::234::MAC1, How can I tell if it is in my site... an admin can pick
234 on both sites right?

My point is we are only on the same site if a packet is sent to or sourced
from a site local address?

> the site-local only link.

I kinda thought the above scenario is rather lame and will not happen. If that
is true my rules (I will post them when I switch back from windows back
to bsd.. ) should work without problems...

> within their site at both ends.

I am missing how..

If the only clue I have is that the from address is a global address, if
inside site local addresses are listed (in TLV's) how do I tell the peer
is on my site?

> like multihoming on IPv6 stack.

We may need to converse over the phone to get this
worked out... since I am still missing something..

R

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 10 May 2001 12:43:51 -0500

Randy/Jim:

Interesting discussion... But I have to admit it is still not quite
clear to me how we should deal with the link-locals. Let's see an
example:

A dentist who bought a pair of IPv6 machines wants to add a little
redundancy to his office networking, he decides to put two interface
cards to each of the machines and connects them with two separate sets
of cables and then boots machines up. Now he starts an SCTP-based
application on one of the machine to communicate with the other
machine... The question is: will the SCTP be able to give him the
networking redundancy he's been hoping for?

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 10 May 2001 12:58:27 -0500

...
> Value = 128bit IPv6 Address

This may be a little crazy, but what if we expand the IPv6 addr
parameter to also carry the site identifier? Will that help? 

-Qiaobing

---

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

Randall Stewart wrote:
> Qiaobing Xie wrote:
No and having waded into this swamp and coded the IPv6 ref-impl I will
attempt
to explain why:
 
1) A link local address is only valid on a single interface.
2) A link local address is unique ONLY on a interface
3) When you send to a Link Local address you specify the interface via
   the sin6_scope_id.
4) If you do otherwise (there are some implementations that just look in
   there neighbor cache to figure out which one to send to but this is
WRONG),
   you cannot send the packet... you will get a unreachable error..
unless
   you have a scope id.
5) If you atempt to do what some bad implementations do (a O/S I deplor
   I am told) then you have a distinct possibility that the same
   Link-Local address exists for two different peers.

Now this all may seem a bit vague but consider...

If I list a Link-Local address in a SCTP parameter, how do you have any
idea which interface it goes to... And even if we had a field for it,
there is no way the sender of the SCTP chunk can know what scope_id has
been assigned to the interface he is sending to on the peer... 

It just DOES NOT WORK!!
 
So for our dentist friend, if he wants multi-homing, he will have to buy
a router (hopefully a cisco one :-/... but even a freeBSD machine can do
here.. though I may hate to admit it :->) and set it up to advertise
site 
local subnets.
 
Then he can INIT destined to a link local or site local and his peer
will add the link-local (since it is a from address) and add all of the
site-local addresses gaining our dentist friend his multi-homing..

There is just NO WAY you can make two lans redundant with no routers
in IPv6 using link-local addresses..this statement is made from having 
implemented the link local junk...

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

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 May 2001 13:12:26 -0700 (PDT)

> networking redundancy he's been hoping for?

This exact question was asked by you, I remembered (or was it La Monte?),
at the Pittsburg IETF.  And I believe the conclusion was that the poor
dentist wouldn't get the redunduncy unless SCTP had the add/remove addr
capability.  To me, this is one of the major reasons why I think the
add/remove addr capability is needed, even though I don't think it is
a good idea to add new things to SCTP at this point.

							K. Poon.
							[email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 10 May 2001 16:42:22 -0500

...
>    there neighbor cache to figure out which one to send to but this is WRONG),
>    you cannot send the packet... you will get a unreachable error.. unless
>    you have a scope id.

But none of the above seems unique to SCTP! What if the dentist starts a
TCP application instead of an SCTP one? How the TCP appl is going to get
around these issues?

Or, is IPv6 multi-homing over multiple link-local addresses itself an
unsolved issue?

> here.. though I may hate to admit it :->) and set it up to advertise site
> local subnets.
 
What a shame if at the end sctp won't help the "poor" dentist...
considering that this "dentist office" scenario was one of the highest
profile stories to show people why IPv6 is a far better design than
IPv4... but now with SCTP, the dentist still needs to take a class on
how to set up a (cisco) router :-) 

regards,
-Qiaobing

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 May 2001 16:20:28 -0700 (PDT)

I strongly recommend that we hold on putting this in the bis document.
(Off topic, what does bis stand for and what does it mean?)  It is not
clear to me that there is any consensus on how it works, even for v4.
To put special rules which we don't have any real world experiment in
a protocol specification is not a good idea.

>      A1) The INIT chunk MUST NOT include any IPv6 Link Local

Seriously, I don't know if it is a MUST.  Consider a machine with
2 interfaces on the same link.  This can be a setup to avoid single
point of failure of a NIC.  If the user app knows about this setup,
I don't see why it MUST be prevented.  If it is in the spec, this
means that this kind of setup is prohibited by SCTP.  It does not
seem to be a right choice.  It may be that after some experiments
we find that this is really a stupid setup and should be avoided,
but I don't know if the spec MUST prevent this kind of experiments.
One reason we should hold on.

>          address parameters SHOULD be included in the INIT chunk.

Since it is a SHOULD, it is not a problem.  But as we have discussed
before, what to include is really a matter of policy.  I can see certain
kind of apps may not want to include any global addresses in the INIT
chunk.  I think it is not wise to recommend certain behavior which
does not seem necessary.

>          IPv6 address parameters in the INIT chunk.

A DNS server can return both site and global addresses.  So if it
just happens that an app picks the global address as the destination,
the app should be allowed to add site local addresses if it knows that
the destination is in the same site.

We may eventually want to have this rule, and require apps to always
use site local addresses as destination addresses.  But without any
experience, I don't think it is appropriate to enforce this at this
point of time.

>          address parameters in the INIT chunk.

I think we are really getting into some unknown territories...  Again,
I don't think we should prohibit experiments on this kind of interesting
setup...

>      B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local

I think the example above in A1 also applies here.  I think there
may not be any straight rules which can be applied all the times.

>          and Global IPv6 address parameters SHOULD be included in

I think A3 discussion above applies to B2 and B3.

>          include any Site-Local IPv6 address parameters in the

I think we can use the example in A4 above.  If there are site local
addresses in the INIT chunk, SCTP may also want to reply with site
local addresses.

>          include any Site-Local IPv6 address parameters in the

This is the flip side of A6 (should be A5) above.  I don't know if
it is really necessary.

I don't think there is a real hurry in making rules for v6 addresses
selection in the bis document because I don't see a deployment issue
even if we don't have the rules.  An implementation can always choose
to use global v6 addresses to communicate.  The problem I have is that
we just don't have enough experience on this issue to make appropriate
decisions.  As I mentioned before, we don't even have suggestions on 
selecting v4 addresses.  We should not jump into conclusion too soon
on v6 addresses selection.  We definitely don't want to have a bis on
the bis document (is bis used correctly here?).

							K. Poon.
							[email-masked]

---

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

> Or, is IPv6 multi-homing over multiple link-local addresses itself an

TCP NEVER has the issue... think carefully on this..

You connect TO a link-local address only.. basically the same
rule I am using for SCTP.. this IS the same solution that you
get in TCP...

> how to set up a (cisco) router :-)
No this is NOT true.  A dentist is NOT going to put in a multi-homed
site unless he is far from "poor". If it is all in a small office I
can't see the need for multi-homing.. in fact most would not even
realize the need for multi-homing... if they do they are far
more techncially astute then the common dentist is and are either:

A) making enough that they will hire a consultant or a dedicated person

or

B) will set it up themselves, either on a cisco router OR a BSD type
box.. by
   the way setting this set up at my house, on a freebsd box (my routers
are
   on order) took about 20 minutes...

Now I think this is not hopeless besides... in a dentists office (like
it has been
advertised) everything will still work... you plug in a couple of
machines
and you can have them talk to each other...  if you want to type in long
addresses :<
 
If you want multi-homing I think by definition you must be a bit
more sophisticated than the "poor" dentist..

I just don't buy your argument.. and besides even if I did this is
a fundamental limitation or design constaint of IPv6 Link Local Address
i.e.
they are NOT valid outside the interface card and network they are on..

It was designed that way ... I beleive the Site-Local was designed for
the "poor" dentist that does not want to hook up to the Internet but
wants multi-homing... i.e. multiple sites on different subnets...

R

---

From: Jim Bound <[email-masked]>
Date: Thu, 10 May 2001 22:46:05 -0400 (EDT)

Hi Randy,

> what a sin6_scope_id is.. but not this other one. So this may be my problem....

Its the interface index or link datastructure.  Holds information about
each interface and connections on that interface.  That is where I believe
we must add a site identifier that is unique to that node.  Thats most
likely whats not in the IPv6 Interface Structure yet and saying we must
have to make site-locals do what they need to do not just for SCTP but for
IPv6 in general.  Then each protocol control block entry for each IP
address would be able to access this structure.  In additon to the
site-identifier (which is the sin6_scope_ID) an adjacent new field would
hold upper 64bits of the prefix for that site.

So we would have:

FEC0::123567F\64  (also FEC0 tells one its a site-local unicast address)
                  (so you can distinguish site-local from global)j 

> good change the peer is NOT on my site...

Not discussing that problem but I will. Thats a different issue. One way
to do this is with address selection ruleset which would be similar to the
IPv6 source address selection draft and could be the same to enter the
site-local instead of global in the parameter.  

But if you were to use a site-local address in the parameter which I was
answering one would check it against the variables above.

> Now if I am sending to a site-local there is no problem since
then > I know the peer is ON my site OR the INIT will fail...

Yes that can be used but it could be checked and avoid the network noise.

> the peer receives the packet FROM a site local...

Does the above addition to ifnet* help.  But it will be ifnet6* or should
be.
 
> This is my fundamental question...

Well you can look at the prefix to see if its global or site.  All
addresses are scoped.  In fact we are discussing now for sin6_scope_ID the
first 4 bits are scope_ID and the other 28bits are the zone ID or site ID.

Why would one care about sending a global unless as I say above you want
site if you know there is peer address for your site ID for your
site-local addresses.

> FEC0::234::MAC1, How can I tell if it is in my site... an admin can pick

Yes.  But if the adm did not pick the same site-id for the address it can
work.  Ah I made that assumption.  If we don't want to make that
assumption then there is no way to differentiate.  But if the adm did.
Then we could tell FEC0::234::MAC1 will not be the same as
FEC0::235::MAC2.  Then using site-local will not work.  Also theoretically
the MAC could be duplicated too.

>from a site local address?

Yes that is true.

>inside site local addresses are listed (in TLV's) how do I tell the peer

If the admin does not permit duplicate site-ids:
  if (site_prefix_of_TLV_addr_parm_1 == ifnet6->siteid_of_any_interface)
     OK_use_that_address
  else not_happening

But the premise is do we assume the adm has done the right thing.

>worked out... since I am still missing something..

OK...sorry day job ate up the day today.  I will send private mail.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 10 May 2001 22:51:14 -0400 (EDT)

Qiaobing,

This is good point and should be permitted I guess :---)
They could use site-local in this case FEC0::MAC1 where site-id == 0.
And then they would have to auto-assign that which is not in the specs at
present and that would take going to ipv6 wg.

The other answer is let it happen and if two nodes do this not on the same
link it will just fail.

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 10 May 2001 22:54:05 -0400 (EDT)

I like that buy a router.  I vote for that.  Forget my last message.
You said what I wanted to say.  It just won't work.

/jim

---

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

Qiaobing,

The issue for link-local is to know the link failed and the other one can
be used.  It may or it may not.  If its on the same link yes it will
happen but that is not really multihomed but multiadaptered :---)

A friend of mine has an idea to do this and make it work but we were not
sure people cared???  If you think its important I can ask them to bring
this up to ipv6 working group or the multi6 working group.

I kind of agree with Randy about the poor dentist.  Do you really want us
to fix that?  I think they can buy gateway boxes for $300.00 for two or
ten machines.  ???????????????

thanks

/jim

---

From: Randall Stewart <[email-masked]>
Date: Fri, 11 May 2001 06:31:22 -0500

Jim:

I tried the above when I was coding up the v6 ref-impl.. It does not
work
and here is why:

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

R

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 May 2001 09:19:23 -0400 (EDT)

Hi Randy,

Good point.  And messing with nd cache is bogus it will kill performance.
The dentist is not poor I they should buy a router.  Also I don't think
link-local should be used for much except config and control not real
apps. Not a popular view though.

I joined sigtran list.  This is showing a big weakness still in our Ipv6
implementations and its around scoping so that is valuable too though I
hate to admit it.  I think what we find for fix for sctp site-local will
apply to current strategy for Ipv6 deployment in general till we do more
code with scoping.

/jim

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 11 May 2001 08:38:28 -0500

Kacheong Poon <[email-masked]> writes:
> [Qiaobing Xie <[email-masked]> writes:]

Yes, this is my "Clever Dentist" example.

Randy does a nice job of explaining why this doesn't work.

I actually had a particular person in mind (who is actually a Clever
Orthopedic Surgeon).  I had to concede to Randy that she would
probably buy a router and set up site local addresses.

Indeed, this doesn't even work if you put addip into the mix.  How do
you get the other link-local addresses of your neighbor so that you
can send the addip requests?  Remember, you can't mention a link local
address anywhere but on its own link.

Jim Bound decided to toy with my hopes and proposed automatically
assigned site local addresses, only to dash them a moment later.
Perhaps there is a niche for ultra-low-cost devices that just
advertise site local prefixes.

The thing that bothers me about this case is that if the Clever
Dentist sets this up, it LOOKS LIKE it works, until there is a
failure.  At that point she discovers that the extra equipment really
added extra points of failure.

Qiaobing Xie writes:
> [Randy Stewart writes:]

[In a later note, Randy describes the uniqueness of SCTP in this
context.]

In a way, there is an issue for TCP here.  It looks like we've added a
redundant (i.e. failover) link which we could use for separate TCP
connections.  In fact, we've added a second component whose failure
could disable the whole network.
-- 
La Monte H.P. Yarroll      Home:                [email-masked]
   If you remember nothing else:  [email-masked]         NIC Handle: LY
   GPL - "Just give source a chance."

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 11 May 2001 09:43:52 -0500

> One reason we should hold on.

There are known problems with a single host having multiple NICs on
the same LAN even with IPv4.  There are interactions between ARP and
the specs for ethernet which make this setup unpredictable.

A LOT of systems get very confused by this configuration.  I've seen
this solution misimplemented more often than I've seen it done
correctly.  The most common misimplementation looks like it works
but has a finite probability (10^-2 or 10^-3) of causing a double
fault when a single fault occurs.

Some OS's that I despise can't handle it at all and will inject really
nasty errors into the network.

There are OTHER ways to get redundancy which are safer and more
stable.
-- 
La Monte H.P. Yarroll      Home:                [email-masked]
   If you remember nothing else:  [email-masked]         NIC Handle: LY
   GPL - "Just give source a chance."

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 11 May 2001 09:46:27 -0500

[I have removed sigtran from the CC list because the sigtran mail
server has been consistently rejecting connections from my home system.
Grr...  Nokia seems to have blacklisted 24.x.x.x addresses.  I'm
removing John Loughney from the cc's too...]

I prepared the following summary of the discussion on IPv6 address
selection for INIT and INIT ACK for my own use.  I think it captures
the principle issues.  I've added my own comments at the end.

Randy Stewart put up two sets of rules which tell us what sorts of
IPv6 addresses to include in an INIT or INIT ACK chunk.  Some are
proscriptive (DON'T do this), and some a prescriptive (DO do this).

Jim Bound suggested that the hybrid Global/Site Local hosts which
Randy described earlier were an unlikely scenario.

Jonathan observed that Site-Local addresses will often work correctly.
He proposed that the inclusion of Site-Local addresses is a policy
issue and should perhaps be controlable by sockopt or a similar
mechanism.

Randy responded that the most obvious choices for Site-Local prefix
are likely to make the collision case more common than statistics
might suggest.

Qiaobing Xie and Kacheong Poon separately suggested that it is too
early to be making rules about IPv6 as we lack significant
implementation experience and do not wish to unduely constrain the
solution space.

Kacheong Poon further asserted that there is no deployment issue for
SCTP even without the new rules.

Jim Bound (our resident IPv6 expert) weighed in with an endorsement of
the proposed ruleset.

Now my comments:

1. We DO have some implementation experience and we learned things from
it at the bakeoff.

2. I believe that we should only add the rules which prevent deployment
problems (blackholing).  [See specifics below.]

3. I think there should be a mechanism for local administrators to
override these rules.

4. Perhaps we can narrow the scope of the necessary rules further by
offering destination address selection advice.

5. Devices residing in a DMZ will almost certainly have both Global
and Site Local addresses.  I'm still not convinced that we don't need
to make failover work for this case.

>          address for an SCTP packet containing an INIT chunk.

I agree with this wholeheartedly, and appreciate the extra clarity of A2.

>          address parameters SHOULD be included in the INIT chunk.

This rule is not necessary to prevent blackholing, though it is a
good idea and should probably appear in a BCP.

>          address parameters in the INIT chunk.

A4 and A6 are the necessary rules to handle the blackholing problem.
These are the rules which I believe need the option of an
administrative override.

>      B1) The INIT-ACK chunk MUST NOT include any IPv6 Link Local

Good.

>          Global IPv6 address parameters SHOULD be included in the

OK.  This rule interacts with the choice of source address for the
INIT ACK.  I'm not certain that extra verbage is necessary.

E.g. if I chose a Global source address I CAN'T include Site-Local
addresses.  I probably SHOULD use a Link-Local source address (to
maximize my address set), but I think that moves us out of
interoperability and into BCP.

>          and Global IPv6 address parameters SHOULD be included in

Rule B3 is pure BCP and is not needed to prevent blackholing.

>          include any Site-Local IPv6 address parameters in the

Is it an error for the INIT to come from a Global address yet contain
Site-Local addresses?  I think so.  OK, rule B4 is necessary and does
not require an override.

>          include any Site-Local IPv6 address parameters in the

This is a lot tougher and I don't think the IPv6 scoping rules help us
much.  I don't think it is illegal to mention Site-Local or Global
IPv6 addresses in a packet with an IPv4 source.

I see why B5 is necessary, but I'm pretty sure I want to be able to
override this behaviour.

---

From: Randall Stewart <[email-masked]>
Date: Fri, 11 May 2001 10:09:40 -0500

Nice summary comments below..

La Monte Henry Piggy Yarroll wrote:
> server has been consistently rejecting connections from my home system.]
> 

I think this should be in the BIS... the reason being it is a
SHOULD which means you may or may not do it.. but it most importantly
is telling you when you CAN send a site-local... I don't like strictly
saying thou shalt not...

> These are the rules which I believe need the option of an

If you do a admin override you open up a black hole...but hey you
can always shoot yourself with admin options :)

> interoperability and into BCP.

Huh? what do you mean LinkLocal source address? You get a link local
when you send to a link local.. if you send to a Global your source WILL
be a Global... I don't see what you mean..

> Rule B3 is pure BCP and is not needed to prevent blackholing.

My same reasons apply ... see above...

> IPv6 addresses in a packet with an IPv4 source.

I think you can mention IPv6 globals.. but if you mention a site-local
the black hole opens up again...

> I see why B5 is necessary, but I'm pretty sure I want to be able to

You can always shoot yourself in the foot.. the spec should not make
it so you can.. Build your setsocketopt() all you want but the MUST's
above should be the rule... and if you want to shoot yourself by
calling your socketopt..go ahead...

R

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 11 May 2001 09:17:01 -0500

Now my comments:

Good.

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 May 2001 11:05:00 -0400 (EDT)

Hi LaMonte

Sorry did not mean to dash your hopes.  But if we want auto sitelocal for
the dentist I can envision it but that would require a draft and then to
the ipv6 wg.  Is it worth it?  I am not sure.  If someone writes it I
would review it.

 /jim

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 11 May 2001 11:36:33 -0400 (EDT)

FYI...

SCTP support has now been included in tcpdump's (and libpcap) main cvs
repository. The next release (3.6.3) should be coming soon (probably
within the next month), but if you can't wait that long... you can also
grab the latest cvs snapshot from www.tcpdump.org :-)

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [email-masked]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 11 May 2001 16:04:48 -0500

Hi, Jim,

I don't know how significant this issue will be in practice, but it is
kind of sad to say that multi-homing over link-locals is unworkable in
general. Will this be something you think multi6 will be interested to
solve?

Banning link-locals outright from sctp INIT/INIT-ACK is probably the
easiest route we can take in order to avoid any potential problems
involving link-locals. But the downside is that we will make SCTP
forever non-supportive to any multi-homing or multiadaptered settings in
a router-less environment. 

That's my concern.

regards,
-Qiaobing

---

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

Jim,

> this up to ipv6 working group or the multi6 working group.

The above example is one reason why I think we should not put that
rule set in the standard spec.  If someone just makes SCTP work in a
"multi-adaptered" environment, why should the protocol stack disallow
such setup?  To me, having a MUST just means that no experiement is
allowed.

Note that I am not saying that those rules are wrong.  I am trying to
say that they MUST not be put in the protocol spec.  Implementations
of SCTP should be aware of those issues and make sure that they do
not have those problems.  But putting them in the standard spec at
this point of SCTP development is not appropriate.  It is not the same
as requiring that no multicast address can be used.

							K. Poon.
							[email-masked]

---

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

> the specs for ethernet which make this setup unpredictable.

Are they implementation problems or theoretical problems?  If they
are implementation problems, then fix it.  Note that I am not suggesting
that this kind of setup should be done.  Once again I want to stress
that we should not prohibit something perfectly legal in some situations
in a standard spec...

							K. Poon.
							[email-masked]

---

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

> general. Will this be something you think multi6 will be interested to
Q:

I don't see how you could ever make a link local ... which has no scope
beyond the net it is plugged into by defintion and thus peers can
use the same address on oposite networks....  can ever be made
to have multi-homing work on link locals... if you make it work
you have to change the defintion of what a link-local is... I
think this is the whole point of site-local :-/

> a router-less environment.

Routers are cheap... buy a few from a good company :)

seriously.. my router is a 100meg pentinum with freebsd. (it will
change soon to a cisco 3620 but for now its a old recycled
pentinum I) .. you can
buy an old one of these for just a few bucks... I don't think
it is such a bad thing that you are required to have routers...

When I first read the IPv6 spec this struck me.. that you really
HAVE to have a router... to make it work...

that is just the way it is..  however hardware is cheap.. but
you get what you pay for :)

R

---

From: Jim Bound <[email-masked]>
Date: Fri, 11 May 2001 23:39:39 -0400 (EDT)

Hi Qiaobing,

> general. Will this be something you think multi6 will be interested to

I don't know.  But I doubt it as they are trying to make sure the Internet
keeps running better with IPv6 when a node is multihomed to two ISPs on
two different links.

In fact SCTP is clearly one solution that appears to be very helpful. 

With SCTP the app will just use the other endpoint.  And there are other
means to do it too and step 1 then step 2.  

This will reduce the state and aggregation in the routing tables if we 
distribute some of the problem to the end nodes.

Link-Local has properties that just limit it.  I don't think thats bad.
A dentist can always ifconfig what they want for addresses too.

> That's my concern.

There will be work in the future to determine if there is a way to do
Duplicate Address Detection (DAD) across links. This means that then
link-local could be used in more situations because at least the dentist
can assume the link-locals are not duplicated.  But that idea will not
fruition for years.  When it happens why can't it be revisited with an
update if in fact they can now be permitted by SCTP.  So I hear your
concern but I believe we can always extend SCTP if we really need to.
Look how much we have done to TCP over the years.  Lots.  And it would
require no change to the architecture or protocol just a permission of a
"new" parameter.

But the risk to SCTP of current link-local addresses cannot be warranted
to risk the chance of non-interoperability to this new protocol you all
have worked so hard to get done and implemented and believers like me.

Why screw it up for a Dentist :----) (actually I really like my Dentist
too he is great and painless which I really like, and he has a little
router running NAT grrrrrr....)

Also if you all don't come to consensus real quick and prevent this from
festering it will hurt the SCTP momentum.

Sure some will have to change some code I am sure.  Heck I can't believe
how many times I had to re-port the IPv6 stuff as we evolved the Base IPv6
API.  And the beauty of Randy's fix is that site-local will work where
there is in fact site-to-site connectivity.

regards,
/jim

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Sat, 12 May 2001 00:09:31 -0500

> Nice summary comments below..

Glad you liked it.

> is telling you when you CAN send a site-local... I don't like strictly

The correct word for telling you when you CAN do something is "MAY"
rather than "SHOULD", but I won't quibble too much...

> can always shoot yourself with admin options :)

Doesn't the spec have to give us permission to shoot ourselves in the
foot?

Would you be OK with adding SOCKOPT_SCTP_SHOOT_FOOT_SITE_LOCAL to the
API?  It would disable A4, A6, B4, and B5.

> My same reasons apply ... see above...

OK, by "MAY" again, rather than "SHOULD".

> the black hole opens up again...

Well... Shouldn't RFC 1918 address be treated as site-local?  I recall
some random exclamations at the Bakeoff...

> calling your socketopt..go ahead...

As long as there is a STANDARD method for shooting at feet.

---

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

> some random exclamations at the Bakeoff...

Well.. maybe.. it makes sense to me... but I don't know...

You could very well get a black hole situation if  you send
a INIT through a NAT for example... but of course a proper NAT
that is SCTP aware will (yuck) reach into the INIT or INIT-ACK
and tweak the addresses...

R

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Sat, 12 May 2001 07:53:20 -0500

Glad you liked it.