<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><blockquote type="cite"><blockquote type="cite">And this goes to your point (4), which I quote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">4. The availability of ULA-C for internal addressing will likely make PA addressing facing the Internet more palatable at least for some classes of enterprise users. This might be implemented with NAT66, multiple RAs, or any number of possible future solutions. Like maybe some variation of LISP, or some other GSE type solutions. But, the details are irrelevant that is an operational issue not a policy one. <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Of the arguments in your message, it would seem to me that this one, combined with whatever security argument one would be the ones that should be further developed. <br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Do you have suggestion how to further develop this argument?<br></blockquote><br>I wrote the above because I don't understand how (4) is a driver, and so I presume others don't either.<br><br></div></blockquote>Regardless of your opinion on the subject (and mine is well known), there is a fraction of the community who believe that having ULA addresses for your interior and mapping those through NAT66 to provider assigned addresses is a good solution to the difficulty of renumbering and necessary to make IPv6 deployment palatable in their enterprise.</div><div><br></div><div>This is the rationale behind point 4 being a driver.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">In addition, given that ARIN and the RIRs have demonstrated reasonable flexibility in terms of making changes to policies, one could reasonably ask the question as to whether this proposal is well timed. <br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Could you clarify what you mean here, are you suggesting this should wait? If so, to an extent I agree, we realistically can't take this up until the Fall ARIN meeting, is that still to soon? However, as I discuss in my response to Chris, this issue is at least partially entwined in a couple policies that will be discussed next week in Toronto.<br></blockquote><br>I'll put it another way: is there substantial customer demand for a service such as ULA-C? I don't see it. Until such time as others see it, why would we execute so soon? With regard to NCNs, I can see them being related; but again, the policy process is pretty flexible. In as much as demand is there, I would let that be the determining factor for timing, so long as we don't make decisions that would foreclose options or do not properly steward the space. Do you see that happening here?<br></div></blockquote><div><br></div>I do not know the size of the demand, but, there are at least a few vocal proponents of the idea. In fairness, they seem to be about the same in number as the vocal opponents of NAT66. It is almost impossible to determine the size of the constituencies lined up on either side, and, I suspect the vast majority of the community doesn't really care as long as they can get to their preferred content.</div><div><br></div><div>Owen</div><div><br></div></body></html>