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

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

Robert,

Site identification requires a site-zone-id to differenentiate fec0::1 from fec0::1 on a node with two sites.   Under the site-identifier for the two sites are local links that also require zone ids for the link-locals.  

So the structure for an interface requires site-zone-id and then within each site link-local-zone ids.  

What I am saying is the site-id abstraction now requires another level of indirection when determining which interface the packet should be sent for interface data structures, routing data structures, and tansport data structures.  It also requires more intelligence for SCTP as example that uses addresses as failover in this case.  For site-local just the addresses is not enough but also the site-id now.

Rather than debate site-local existence maybe it would be good to just get consensus on their complexity and what they mean regarding added work for implementations?  

But as someone pointed out to me privately I don't want people printing on my site printer from the Internet.  So is it the job of the address type or the filters in IPv6 routing or firewalls to prevent that?

Hope this helps with my initial issue.

/jim

> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 12:43 PM
> To: Bound, Jim
> Cc: JINMEI Tatuya / ????; Margaret Wasserman; Brian Haberman;
> [email-masked]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols 
> 
> 
>     Date:        Mon, 17 Jun 2002 10:19:13 -0400
>     From:        "Bound, Jim" <[email-masked]>
>     Message-ID:  
> <[email-masked]
> qcorp.net>
> 
>   | 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
> 
> 

--------------------------------------------------------------------
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: Fri, 21 Jun 2002 15:39:27 +0700

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

  | Site identification requires a site-zone-id to differenentiate fec0::1
  | from fec0::1 on a node with two sites.

Absolutely, as does link local for fe80::1

  | Under the site-identifier for the two sites are local links that
  | also require zone ids for the link-locals.

Yes, though I wouldn't say "under" (though I guess you can draw it
like that).

  | So the structure for an interface requires site-zone-id and then
  | within each site link-local-zone ids.

Not within - an interface has a site-zone-id and a link-zone-id yes
(though an implementation could probably combine those into one number
if it wanted to - treat the whole value as the link-zone-id, and some
number of bits of it as the site-zone-id).

  | What I am saying is the site-id abstraction now requires another level 
  | of indirection when determining which interface the packet should be sent

No.   If the address is link local, you have to consider the link-zone-id
(and perhaps just that - depending upon the multi-interface link stuff).

If the address is site-local you have to consider the site-zone-id, and
the forwarding table.

If it is global, you consider neither id, just the forwarding table.

So, while there is a little bit of extra code involved here, the mechanisms
to consider the zone-id, and the forwarding table, both already exist.

  | for interface data structures,

Maybe one extra number.   This I don't think counts as lots of
extra overhead...

  | routing data structures,

yes, routing is the one place where there is some extra work, but
not anything extraordinarily difficult I don't think.

  | and tansport data structures.

No, nothing needed there at all - there needs to be a zone-id field,
but that's needed in case the transport is using LL addresses (like BGP).
If it is using SL addresses, the same field can be used for the site-zone-id.

  | It also requires more intelligence for SCTP as example that uses addresses
  | as failover in this case.  For site-local just the addresses is not enough
  | but also the site-id now.

As would a fail-over to a LL address require the link-id.  Nothing new
added by SL's there.

  | Rather than debate site-local existence maybe it would be good to just get
  | consensus on their complexity and what they mean regarding added work for
  | implementations?

Yes, if we could get consensus on that - but I would never set implementation
work as the arbiter by which we decide upon what we include and what we
exclude.   If implementation work was the test, then nothing involving
security would ever be implemented.

Eg: look at the other discussion going on in this list (another
discussion anyway) - related to securing neighbour discovery.
Unless "do nothing" is the outcome from that, that's likely to
require lots more implementation than anything related to SL's
(even assuming the answer is just to use ESP or AH, assumed to
already exist).

  | But as someone pointed out to me privately I don't want people printing
  | on my site printer from the Internet.

That's probably true (though at Melbourne for a while we had a printer
established precisely to allow people (anyone) to print from anywhere...)

  | So is it the job of the address type or the filters in IPv6 routing or
  | firewalls to prevent that?

Firewalls absolutely.   The "I can use SL addresses to restrict nodes so
they can only be accessed locally" argument that is occasionally made
seems to serve not much better purpose than be easy to show how flawed
it is.   Site local addresses are for address stability, not for security,
information hiding, or any other dumb uses like that.

kre