ietf
[Top] [All Lists]

Re: Architectural Considerations section in specs

2003-04-23 16:28:27
Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Tony, this discussion is about ambiguous addresses.  Your persistent
attempt to conflate it with packet filtering and/or routing policy isn't
shedding any light on the argument.  And you're smart enough to know
the difference.

And you're conflating ambiguous addressing with scoping.

You cannot expect apps to not leak addresses outside of their scope
because apps do need to pass addresses around and they have no
way of being aware of their scope boundaries.  The way to solve this
problem is to make addresses unique.

Give everyone global addresses and the scoping problem remains unchanged.
Even "global" addresses are scoped by administrative or security policies.

Having a prefix set aside for private addresses, whether SL or RFC1918, is
convenient for humans, that's all.  It may make scoping easier or more
common, but it's not the cause.

There is no magic here, and defining a prefix didn't change the
architecture.

defining a prefix didn't change the architecture - asserting that the
same prefix could be reused in multiple locations did change the
architecture.

Perhaps.  There is no functional difference unless multiple instances of the
same address are actually _reachable_ by a third party; the mere existence
of duplicates does not change the architecture.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking