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

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

Folks,

Randy's fix works.  You should but this into the bis.  You don't want to
make 2960 have a bug or interoperability problem with IPv6.  The fix will
work.  If by some new feature or networks do something new it can be
extended.  This way you nip it in the bud as a WG and move on.  I do think
if Steve Deering thinks the fix is good you should do it too.  Anything we
can do to make this scoping a done deal in SCTP is wonderful for IPv6.

Also randy is right on link-local.  I tried doing some pretty strange
things with them with duplicate links and multiple interfaces years ago
using ping to multihome it.  When we faked the sin6_scope_ID. Some things
just don't work and link-local is not good for.  We also saw limitations
of link-local with DHCPv6 too.  Link-Local is great for neighbor discovery
or other discovery and best of all it got rid of bootp.  But its not good
for other things at all.  Its a tool for IPv6 and has its place.  As is
site-local.  But all tools should not be used for all situations right.

My 2cents......

/jim

On Fri, 11 May 2001, Randall Stewart wrote:

> 
> Kacheong:
> 
> with a bit of ftp and other hookery I now can reply to this
> message... messages that do not cc me directly at my cisco addres
> in general are delayed until I can do extra work to get them :< still
> have the northpoint flu....:<<
> 
> 
> Kacheong Poon wrote:
> > 
> > > Well, could we just ping some people on this subject (form even
> > > a mini-design team) to work this out for the BIS draft.  As
> > > SCTP & IPv6 will be seeing deployment in the 2nd half of the
> > > year, I think we should at least get a good solution for this
> > > soon.
> > 
> > Talking about selecting the correct set of addresses in the
> > INIT/INIT_ACK chunk, I don't think we have a good idea about
> > what to do with v4 addresses, let alone v6...  I remembered
> > we had a brief discussion about this some time back.  But I
> > don't think anyone has come up with a good solution.  And
> > it seems to me that this kind of address selection will
> > necessarily involve site policy.
> > 
> 
> I disagree with this Kacheong. We do know what address set you
> send.. and even more so we MUST have some sort of specification
> in the IPv6 world or we will surely create a black-hole problem.
> 
> 
> > Just for an imaginary example, every machines in a company has
> > 2 IPv4 addresses, each from a different ISP.  So the policy may be
> > that talking to another site of that company should not use
> > addresses from ISP x because of, say, security and cost.  I think
> > people can come up with all sorts of other examples which a policy
> > is required.
> 
> And there are ways to only bind a single address... or use the
> del-ip address in the add extension to knock off one from
> consideration..
> 
> > 
> > This leads me to think that whether it is appropriate to
> > include this kind of discussion in the 2960bis.  The concern
> > is that it is not really a protocol issue.  It becomes an
> > implementation or system administration issue.  And I don't
> > thinkt it is a good idea to include this kind of dicussion in
> > a protocol standard.
> 
> Oh I most whole heartedly dis-agree. Any time you have an
> issue that can make a protocol die... with a OOTB abort from
> a site local that you listed that was duplicated at a local site..
> it becomes a protocol issue. Otherwise you end up getting 
> SCTP connections that break at random times in unexpected ways..
> 
> > 
> > On the other hand, if we know of something that definitely
> > should not be done, we may consider it putting in 2960bis.  For
> > example, if the INIT chunk does not have a link local address,
> > SCTP should not include any link local addresses in the reply.
> > But the reverse may not be straight forward.  Should SCTP return
> > link local address if the INIT chunk has a link local address?
> > This is tricky.  It makes perfect sense in some cases but not
> > in other.
> 
> 
> No I strongly disagree.. I have been down this road... You have not
> coded it .. I can see. If I put Link-Local addresses inside a
> INIT-ACK you the receiver have NO WAY to know which sin6_scope_id
> goes with the Link-Local address... and the sender has NO WAY of 
> knowing what our scopeid is even if we had a way to send it.
> 
> Link local addresses will ONLY work if the IP source/destination
> in the actual IP datagram (from address in some of my previous
> email) has a link-local address..
> 
> > 
> > So I'd suggest not putting this kind of discussion in the bis,
> > but have another document discussing this issue.
> > 
> sorry, I disagree. This is a very very important inter-operability issue
> that
> by ignoring will cause horrible problems in the future...
> 
> R
> 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> 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]
> 

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

---

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

the default should not assume NAT.  That is absurd\ IMO.  

/jim

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

> Erik Nordmark wrote:
> > 
> > > The above i.e. you don't list site local unless the to/from is a
> > > site local is EXACTLY what the BIS document has in it right now.
> > > This is the main point that Jonathan Woods and Kacheong Poon object
> > > to...
> > 
> > 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.
> > 
> 
> 
> Ok, after a sidebar conference call... I do now know a reason why one
> may want to source from a site-local destined to a global... And the
> ugly reason is... NAT.
> 
> If one has a NAT, for whatever reason, then your source MAY want to
> be a site-local... destined to a global...
> 
> Of course then we would still have the problem of unreachable
> site-locals
> in the INIT/INIT-ACK list... but I guess a "good" NAT would reach in
> and tweak these... yuck! I hate NAT!!!
> 
> Now on the other hand, let us assume for some other un-thought of reason
> you sent a INIT/INIT-ACK with a site-local in the source. You are
> required
> to respond to the source so if routers/hosts let this To:global
> From:site-local
> be sent, the poor receiver would send back its answer (say a INIT-ACK)
> and of
> course would either NOT be able to reply OR some other host (on the
> local site)
> would drop the (in it's view) invalid INIT-ACK...So I think no matter
> which
> source/or destination is site-local.. we do not have a black-hole
> problem and
> I am convinced its ok...
> 
> R
> 
> 
> 
> -- 
> Randall R. Stewart

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 15 May 2001 13:12:29 -0700 (PDT)

> I think we can do it here because its is a minor subset of IPv6. In IPng
> the SCTP learning curve will be to great.  Let me post my tech position
> before we give up here.  I think this can be cleared up quickly.

First, if the selection guideline is still not final in the ipngwg, how
can we have a strict guideline in SCTP?  And I'd say the rules just 
intersect, SCTP's rules are not merely a subset.  There are other issues
in SCTP that I think the ipngwg slection guideline will not and does not
need to cover.  As I suggested before, let's wait and see how things will
turn out.

							K. Poon.
							[email-masked]