Richard Draves writes:
> > > Yes, needless complexity is bad. But site-locals don't add any
> > > significant complexity to applications (which I think I've
> > demonstated
> > > enough in too many emails already).
> >
> > this is only true if globals are always available to any node
> > that potentially participates in an application that
> > communicates off-site -
> > which essentially means any node in any network which has an
> > external connection.
>
> So to restate - Keith, it sounds like you now agree, that with a
> reasonably small amount of additional complexity, apps can function in a
> network environment that has both globals & site-locals - subject to
> your condition about globals being available for apps that communicate
> off-site?
>
> Certainly - if a node is going to run an application that communicates
> off-site then it needs a global address. I mostly agree with the second
> part - I would say any general-purpose node in any network which has an
> external connection should have a global address.
>
> However I think we will have limited-function nodes, which run a fixed
> set of applications, and if those applications do not need globals then
> the node does not need a global address. I think the vendor of one of
> these devices should have the freedom to determine the device's "out of
> the box" configuration, based on expected usage patterns.
I find this kind of thinking rather suspect. The
question in my mind shouldn't be "why global", but
"why not global". There seems to an underlying
assumption that site locals would give better
security properties due to their global
inaccessibility. I find that rather uncompelling
and misguided as this is just carrying forth the
broken assumption that barriers (firewalls, etc)
can do an adequate job of protecting
things. Anything which propogates that sort of
thinking is, IMO (and almost certainly not in my
employer's) bogus and needs to checked. We need
keep beating the strong auth/authz drum here.
So, let's just take that off the table for this
discussion.
Mike
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
