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

From: [email-masked]
Date: Tue, 15 May 2001 09:46:10 +0300

Hi Erik,

I'm sure that I am missing something ...

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

I think this is the crux of (one of) the problems.  We want to solve
this issue.  Should we solve it by giving rules on how to mix
global addresses and link-local addresses (in addition to site-local)
of course, or do we come up with an implementational way that 
solves this.  Of couse, if we cannot solve it easily on an implementation,
then it is likely we will run into deployment problems.  2960 isn't
sufficient as is, as demonstrated by the recent bake off.

[some text clipped]

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

I'm confused ... I thought that site-locals are only valid for 
hosts which are on the same site.  Shouldn't both the source
and the destination be on the same site for the site-locals
to be valid?

best regards,
John

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

---

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

> sufficient as is, as demonstrated by the recent bake off.

I don't think you need to specify how to mix addresses of different scopes
since I view that as being a problem for the IPNG WG to solve
(by coming to concensus something along the lines of 
draft-ietf-ipngwg-default-addr-select).
Instead SCTP can merely focus on what addresses must not be included
in the INIT/INIT-ACK to prevent leakage.

> and the destination be on the same site for the site-locals

As I've quoted earlier on this thread today that isn't necessary for
things to work. Traffic with e.g. a link-local source and a global destination
will not escape the sender's site. (It might fail by being dropped by
the site border router, which is why it is less preferred than 
a <global, global> combination.

  Erik