ietf
[Top] [All Lists]

Re: Architectural Considerations section in specs

2003-04-23 18:54:47
Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
And you're conflating ambiguous addressing with scoping.

nope.  the property that I'm concerned about is not that an address
may only be usable within a particular portion of the network, it's
that the address is ambiguous.

As Mr. Hain pointed out, last week your argument was about scoping and apps
picking addresses, not about private addresses.

so given an address there's no way to know whether or not it is valid,
or why it doesn't seem to work to let you connect with the
host/peer/server you think it's associated with.

You have no way of knowing if any address is reachable from any particular
location.  That is not a property specific to private addresses.

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.

wrong.  it's useful to have unique names for hosts (or points on the
network) even if they're not directly reachable by everyone who might
possess those names.

Useful, yes; a fundamental part of the architecture, no.

Removing private addresses from the IPv6 architecture is a fundamental
change from IPv4: site-locals are not a new addition, just a different name.

If site-locals are deprecated, the NAT/stable address/whatever crowd will
just pick a different prefix to use.  Worst case, they'll all pick different
ones.  RFC1597 didn't cause the scoped-address mess; it just provided a
reasonably safe sandbox and standard semantics.

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