<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/14/10 2:52 PM, <a class="moz-txt-link-abbreviated" href="mailto:michael.dillon@bt.com">michael.dillon@bt.com</a> wrote:<br>
<span style="white-space: pre;"><br>
> Who says 6RD is bad? 6RD and RFC 5969 which documents it, are
both<br>
> GOOD things because they will accelerate the switch to IPv6.
The<br>
> discussions are about ARIN policies which SUPPORT and
FACILITATE 6RD.<br>
> But the fact is that 6RD is a temporary stopgap measure. That
is not<br>
> bad, that is just the facts. And we should be clear that we
are only<br>
> supporting and facilitating 6RD as a means to an end, namely
native<br>
> IPv6.<br>
</span><br>
<span style="white-space: pre;">> In any case, ARIN is not
involved with 6to4, but ARIN can play a role<br>
> in facilitating 6RD.<br>
</span><br>
I am very glad to see such a healthy attitude of facilitation. We
need it, as we still have quite a bit of hill to push the IPv6 rock
up.<br>
<span style="white-space: pre;"><br>
> ARIN is not the Architectural Regulator of Internet Networks.
It is<br>
> the American Registry of Internet Numbers. ARIN does not run
the<br>
> Internet, not even in the USA. ARIN does not specify the
Internet's<br>
> architecture and design.</span><br>
<br>
Classifying 6rd as a means to an end for native IPv6 is an
architectural statement, though one that is at least consistent with
the 6rd RFC. Limiting the space which 6rd can run, however,
presupposes how the transition from 6rd to native is to be done.<br>
<br>
From RFC 5969:<br>
<br>
The SP can choose to provision a separate IPv6 address block for<br>
native service, or reuse the 6rd prefix block itself. <br>
<br>
An ARIN policy that requires moving to a different block is, by the
letter, an IETF standards-track RFC violation. <br>
<br>
I'm calling this out only to underscore that there are serious
operational considerations with respect to allowing native and 6rd
to coexist within the same prefix while moving to native.
Considerations that could actually discourage movement to native by
ISPs. We want it to be as easy as possible for ISPs to move to
native IPv6 from 6rd. This is why this sentence exists in the RFC.<br>
<br>
Putting 6rd into a segregated block, in particular with the threat
of that block expiring, only adds to deployment hurdles. Today, it
would be one more thing that the poor person at the ISP that
actually wants to see IPv6 deployed before the CGNs take over has to
convince his or her management is not a future risk factor.
Tomorrow, it could be one more hurdle for the ISP to renumber their
IPv6 customer when moving to native. <br>
<br>
I'm all for facilitation. Let's focus on that rather than assuming
we know how the operator is going to migrate from 6rd to native and
encoding that in the ARIN policy.<br>
<br>
- Mark<br>
<br>
</body>
</html>