Date: Wed, 19 Jun 2002 17:41:13 -0400
From: "Bound, Jim" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
