RE: Architectural Considerations section in specs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Crocker wrote:
> Folks,
> 
> DS> I am saddened by the fact that Tony's simple question 
> could not be 
> DS> addressed. Site local addressing in IPv6 is a concept 
> which has been 
> DS> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed 
> DS> Standards. This is a string of documents dating back to 1995. For 
> DS> eight years this concept was apparently considered a good thing.
> 
> The problem appears to have been that no one bothered to draw 
> the necessary implications and circulate them for explicit 
> consideration. So folks scanned a spec, didn't see anything 
> that looked egregious, and only now are realizing how 
> extensive the impact is.

What they are missing is that a defined prefix doesn't create the
problem that they are complaining about. Limiting the usable scope of
addresses is an operations decision. The mismatch between the
operational reality of limited scope addresses and the app developer
fantasy that there is a single flat routing space is the core problem
here.

Defining a prefix for those only made it *possible* for apps to
recognize which ones might be restricted. It does not *make* apps deal
with the problem of leaking addresses outside their scope of relevance
(unless you take the viewpoint that end users actually expect
applications to work right, and will require it once it is possible).
Applications are not required to understand topology, unless and until
they insist on passing around topology specific information. If any
process is going to pass around topology specific information, it MUST
understand the topology it is describing. 

There is no magic here, and defining a prefix didn't change the
architecture. Operational decisions established the architecture, and it
is our job to define the technologies that work within that
architectural reality. We can choose to continue to declare a
'flat-earth' and insist that applications and name resolution
infrastructure are free to arbitrarily pass around topology specific
objects, or we can choose to recognize the reality of the deployed
network and build the technologies that allow applications to operate
correctly within it. 

Tony




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]