<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>This is what security experts (LIKE MYSELF) call:<br>     depth-in-security<br><br></div></blockquote>This is most definitely the shallow end of "defense-in-depth" which is</div><div>what those of us who have been around long enough to remember</div><div>the era before Brent Chapman wrote a book on the subject call it.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>The major advantage of ULA-C is that is provides a much better way to<br>audit what is what, particularly when there are multiple organizations<br>connecting together in various ways.<br><br></div></blockquote>A better way to audit than what? Since you haven't identified what you</div><div>are comparing it to in this statement, it is unclear whether you mean</div><div>GUA, ULA-Random, what I am calling GUA-Tainted (which does not</div><div>necessarily have any distinction on the wire from ULA-C, only in the</div><div>policy and fee structure details), or some other idea.</div><div><br></div><div><blockquote type="cite"><div>It also permits sane auditing of multiple remote-access connections from<br>laptops/etc. for visiting consultants, etc.<br><br></div></blockquote></div><div>Again, I don't see the distinction here, but, maybe with a distinct point of</div><div>comparison, that would be easier.</div><div><br><blockquote type="cite"><div>ULA-C for NCN is much more robust than "tainted" GUA as far as failing<br>closed. <br><br></div></blockquote>Still not seeing it.  ULA-C is a set of numbers tagged as not-routable by</div><div>address policy convention.</div><div><br></div><div>GUA-Tainted is a set of numbers tagged as not-routable by address</div><div>policy convention.</div><div><br></div><div>In fact, I have repeatedly explained that implementation of GUA-Tainted</div><div>from the ULA-C number block would be a fine idea.  As such, I'm not sure</div><div>what distinction you are seeing in GUA-Tainted from ULA-C. There must</div><div>be some depth to the on-wire security implications of address assignment</div><div>methodologies not apparent on the wire that I am not getting.  Please</div><div>do enlighten me.</div><div><br></div><div><blockquote type="cite"><div>But, for it to have any value over RFC1918 (i.e. NOT USING IPv6), it has<br>to solve problems which RFC1918 has caused. <br><br></div></blockquote>Exactly.</div><div><br><blockquote type="cite"><div>Split-DNS is one of those things. (I started implementing split-DNS<br>systems back in 1992... It was useable then because nobody had<br>laptops.  By the time it became universal for enterprises, it was<br>unworkably useless, and /etc/hosts or literal IPs began to replace it)<br><br></div></blockquote>Agreed.</div><div><br></div><div>As Is said earlier, we are, I believe, arguing over form and not substance.</div><div><br></div><div>In addition to the community of users who want tainted address space</div><div>(whether you call it ULA-C or GUA-Tainted), there exists a community</div><div>of users that wants non-tainted address space for networks that are</div><div>not connected now, but, may be connected at some other time or may</div><div>connect and disconnect multiple times over some time period.</div><div><br></div><div>My proposal is to meet BOTH sets of needs using broader GUA policies</div><div>with an ability to provide "tainted" GUA (as I said, this could _BE_ ULA-C)</div><div>to those who request it.</div><div><br></div><div>However, I stand by the assertion that ULA-C or GUA-Tainted being</div><div>made available on a basis which is different (easier or cheaper) from</div><div>the policies under which GUA is made available will lead to accepted</div><div>(ab)use of ULA-C/GUA-Tainted in ways which:</div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre">  </span>Reduce its value as distinct for security purposes</div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Reduce its value as distinct for routing purposes.</div><div><br></div><div>Owen</div><div><br></div></body></html>