Subject: [Tsvwg] Regarding IPv6 address scope

From: "Buraga, Partha S" <[email-masked]>
Date: Wed, 27 Feb 2002 05:51:53 -0500

Hi

If source or destination address of INIT chunk ( IPv6 header ) is SITE LOCAL
address, can i allow the LINK local address as INIT chunk parameter ? 
other way, if source or destination address of INIT chunk ( IPv6 header ) is
LINK LOCAL address, can i allow the SITE local address as INIT chunk
parameter ?

thanks
partha

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Feb 2002 12:11:18 +0100

Hi,

this topic is covered in
http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-00.txt

best regards
Michael

> LINK LOCAL address, can i allow the SITE local address as INIT chunk
[email-masked]

---

From: David Lehmann <[email-masked]>
Date: Wed, 27 Feb 2002 08:58:54 -0500

> http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-00.txt

This draft has expired.  Will this draft become an RFC or
be incorporated into another draft which will become an RFC?

Now about the document text...

Can I get a clarification on A2 and B2?
If I have two machines connected by two separate LANs 
(e.g. two crossover ethernet cables), I can have an 
association using both LANs.  The wording of A2/B2 
seems to restrict the association to the single physical 
link used by the INIT packet.

What if I had two machines connect by two separate
networks.  One is a site network and the other is
the global Internet.  Can I have an association which
uses both networks?  The working of A5/B5 seem to
exclude this configuration.

-David

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Feb 2002 15:27:01 +0100

David,

I personally think that it would be good to resubmit the ID after
inclusion of the experience get will get at the connectathon
(www.connectathon.org) testing SCTP. It starts tomorrow, SCTP
testing will start on Friday.

These issues will definitely be discussed there. Will be be at
connectathon?

For further comments see below.

Best regards
Michael

> link used by the INIT packet.
I think this is a problem. Because you could even use
the same link local address on both interfaces, I think.

> exclude this configuration.
You can include the global addresses if you send the INIT
from the site local to the site local address. The INIT-ACk
will also use the site local one as from/to addresses.
If you send the INIT from and to the global one, you can not
include the site local one.

---

From: David Lehmann <[email-masked]>
Date: Wed, 27 Feb 2002 09:58:23 -0500

> These issues will definitely be discussed there. Will be be at

No, I will not be there.  I am waiting for the next bake-off.
(At the time of registration, SCTP looked like an after-thought
as it did the previous year.)

Please publish the key points of the discussion on tsvwg.

> the same link local address on both interfaces, I think.

I think you are right.  Sun uses the same ethernet address
for all of the interfaces.  Thus, the link-local addresses
will be the same for all... I think.

> include the site local one.

I don't see why this should be the case.  Each destination is 
an equally valid path to the receiver.  Thus, both of the 
sender's addresses should be valid, regardless of the path
taken by the INIT.

IMHO, if the user wants to only use the global addresses,
the user should bind only to the global addresses.

-David

---

From: Randall Stewart <[email-masked]>
Date: Thu, 28 Feb 2002 08:57:31 -0600

David/Michael:

Thre are problems with link/site/global addresses in IPv6
for sure... The draft does need an update... I re-read it
a few weeks back and planned on getting to it... but I ran
out of cycles :<

Even at that there are things I am sure I have not thought
of or discovered in my playing... hopefully at connect-a-thon
we can come up with a more complete set of rules...

A couple of thoughts:

If I send From/To a link local...
  - I can NOT necessarily include all my other link
    locals because:
     a) How do I know that my peer also has interfaces 
        on the same lan's that I do?
     b) Even if I know that my peer DOES have interfaces
        in common with ALL my interfaces, how can I
        know or inform my peer what is the valid scope id
        for his end of our common interfaces... its not
        a problem when he receives from a link local, he can
        dig down and find the scope id off the receive interface..
        but the other interfaces unless the local endpoint is
        somehow configured... and it still can tell the peer..
 
        Remember I may be using fe80::1 on say my second interface
        but my peer may have interfaces a, b, and c. Maybe my
        second interface is on b, but my peer also has a neighbor
        (not me) on c using the same address.  If he gets a INIT
        chunk from me listing fe80::1 he has no idea if I am the
        neighbor on b or c?.

For the above reasons our current BSD implementation in KAME
will only allow link locals to be included if:
   - You are sending to a link local.. but the link
     local is NOT put in the list of addresses.. it gets
     in by inference as being a source address on the INIT/INIT-ACK.

   - Or if you are sending to a loopback address. This we have
     not played with to much though.

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

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

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)