Re: Architectural Considerations section in specs

["Stephen Sprunk" <[e-mail]>]

Thus spake "Keith Moore" <[e-mail]>
> > 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