> - GUPI addresses may also be used to communicate over
> private links with other GUPI-addressed networks.
Or for that matter, to communicate over private links with other
networks that use globals. I don't see why it matters whether the
other sites are using GUPIs or not - all that matters is that you
have unique addresses for your site. GUPIs shouldn't be thought to
have any special significance to apps, they're just a way to get
a unique prefix when you don't have stable public Internet connectivity.
I stand corrected... I agree with you completely.
> - You may have different "levels" of GUPI addresses within
> a single network... Some devices may use addresses
> that are filtered at the department level, some
> may be filtered at the corporate level, and
> some may be filtered at the extranet level, for
> example.
absolutely. of course, you can do this with global prefixes also.
Definitely.
I suspect
that some constraints on use of GUPIs are necessary unless there are
technical means of allowing dissimilar prefixes for topologically
close networks to be aggregated for the purpose of routing computations
and probably advertisements also.
Why to the prefixes for topologically close networks need to be
dissimilar. There is at least one proposal in multi6 for aggregable
provider-independent addressing. I'm not sure how well it would
work, because I haven't examined it in detail...
I don't think we should try to prevent leakage at any layer above
a routing protocol. We certainly shouldn't depend on addresses
not leaking. Sites can implement two-faced DNS if they wish (and
deal with the operational problems that result) but in all cases
app writers need to make sure that their apps do reasonable things
when given addresses that they cannot reach.
Right... And, given the wide proliferation of filtering and
firewalls, they must already be doing this today. IPv6 site-locals
add a new twist -- ambiguous addressing. That's the part I think we
should try to avoid.
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
