Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:13 -0400

> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 3:13 AM
> To: Bound, Jim
> Cc: JINMEI Tatuya / ????; Margaret Wasserman; Brian Haberman;
> [email-masked]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols 
> 
> 
>     Date:        Thu, 13 Jun 2002 08:59:58 -0400
>     From:        "Bound, Jim" <[email-masked]>
>     Message-ID:  
> <[email-masked]
> qcorp.net>
> 
>   | Exactly.  The entire IPv6 code base would be reduced in 
> size and more
>   | importantly the decision constructs and data struct 
> lookups which is a 
>   | big win.
> 
> Can you actually justify that, or is this just more nonsense?

Sure. But I don't respond well to the work nonsense or your tone.  So I won't to you.
Don't start a fight with your attitude with me but if you want to lets take it offline.
Be civil Robert.

> 
> Remember that as long as link locals stay, and as long as their are
> apps that use them (doesn't BGP peering use LL's these days?) then all
> of the system support for scoped addresses has to remain, 
> including the
> data structs, API's, ...

Link-Locals do not have the same properties to implement as site-locals.

> 
> What you would gain by removing them is the change from testing
> fe80::/9 into testing fe80::/10 when deciding if the address you
> have is one that also needs a scope.   Beyond that it is essentially
> all the same if scopes are involved - are the scopes for source &
> destination the same, etc - regardless of whether it is fe80::/10 or
> fec0::/10 that the address happens to be.

Site causes logic beyond the link and causes more errors for TCP, SCTP, and Anycast.
BGP peers using LLs is fine that is a link.

/jim
> 
> So, just where is this saving?
> 
> kre
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 17 Jun 2002 23:43:27 +0700

Date:        Mon, 17 Jun 2002 10:19:13 -0400
    From:        "Bound, Jim" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Link-Locals do not have the same properties to implement as site-locals.

They have almost the same properties (the internals of routing protocols
excepted, as LL's don't go there - obviously, as they're not routed anywhere),

Apart from inside routing, a user of SL's has to specify the scope, just as
does a user of LL's, and the forwarding engine has to make sure that the
packet is sent only to a link in the appropriate scope, in both cases.

Routers (routing protocols omitted for now) need to check that the scope
of the outgoing interface is the same as that of the incoming one, for
both link locals and site locals - for link locals that can be reduced
to checking that the interface is the same (or I thought it could, but
apparently we have multi-interface links now, which makes LL's even closer
to SL's in this area) but it doesn't have to be (and probably can't if
these multi-interface link things exist, whatever they really are).

  | Site causes logic beyond the link and causes more errors for TCP, SCTP,
  | and Anycast.

What errors?    Please Jim - don't just claim something, if there's a
problem, actually give the details, then it will be possible for others
to either see your point, or show you where you're mistaken.

But "causes more errors" is just the same as "this program is broken"
without any more detail - it is a totally useless comment.

kre