<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"SimSun","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-AU link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hey all,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Given the current topic of ‘IPv6 Non-Connected Networks’,
I thought that I would let you know of a policy that is presently in discussion
on the APNIC lists that I submitted.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The crux is that even if aggregation of announcements as a
policy is dropped, there is no policy that satisfies the need of LIR’s to
be able to build non-connected IPv6 networks in the APNIC region.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>With some basic justification, an LIR should be able to gain subsequent
/32 allocations for the purpose of remaining ‘as routable as possible’.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>While APNIC, like other RIR’s do not set routing policy,
they do heavily influence it. And while they cannot control the practice
of community filtering lists based on their own allocation pools, they should
not ignore the situation.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Given that IPv6 is not a scarce resource and by no means am I
suggesting we just burn it for the fun of it, this seems to be a philosophical
debate rather than a technical one. This is due to that even if an LIR
could de-aggregate its /32 to say, 8 /35’s or 16 36’s, these
entries in the routing table would have the exact same result as if they had 16
* /32’s.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So due to this, the only restriction here is the pool allocation
which the community filter lists are based on – which the RIR’s
essentially have created and now have the responsibility to consider.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>...Skeeve<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>--<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>Skeeve Stevens, CEO/Technical Director<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>eintellego Pty Ltd - The Networking Specialists<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>skeeve@eintellego.net / www.eintellego.net<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>Phone: 1300 753 383, Fax: (+612) 8572 9954<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>Cell +61 (0)414 753 383 / skype://skeeve<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>www.linkedin.com/in/skeeve ; facebook.com/eintellego<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>--<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#002060'>NOC, NOC, who's there?<o:p></o:p></span></p>
</div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> sig-policy-bounces@lists.apnic.net
[mailto:sig-policy-bounces@lists.apnic.net] <b>On Behalf Of </b>Terence Zhang
YH(CNNIC)<br>
<b>Sent:</b> Wednesday, 3 February 2010 10:46 PM<br>
<b>To:</b> sig-policy@apnic.net<br>
<b>Subject:</b> [sig-policy] prop-083: Alternative criteria for subsequentIPv6
allocations<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>Dear SIG members,<br>
<br>
The proposal, 'Alternative criteria for subsequent IPv6 allocations',<br>
has been sent to the Policy SIG for review. It will be presented at the<br>
Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.<br>
<br>
We invite you to review and comment on the proposal on the mailing list<br>
before the meeting.<br>
<br>
The comment period on the mailing list before an APNIC meeting is an<br>
important part of the policy development process. We encourage you to<br>
express your views on the proposal:<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Do you support or oppose this proposal?<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Does this proposal solve a problem you are experiencing? If so,<br>
<span style='font-family:"Times New Roman","serif"'> </span>
tell the community about your situation.<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Do you see any disadvantages in this proposal?<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Is there anything in the proposal that is not clear?<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- What changes could be made to this proposal to make it more<br>
<span style='font-family:"Times New Roman","serif"'> </span>
effective?<br>
<br>
<br>
Information about this and other policy proposals is available from:<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
<span class=MsoHyperlink>http://www.apnic.net/policy/proposals</span><br>
<br>
<br>
Randy, Ching-Heng, and Terence<br>
<br>
<br>
___________________________________________________________________<br>
<br>
prop-083-v001: Alternative criteria for subsequent IPv6 allocations<br>
___________________________________________________________________<br>
<br>
<br>
Author:<span style='font-family:"Times New Roman","serif"'> </span>
Skeeve Stevens<br>
<span style='font-family:"Times New Roman","serif"'> </span>
<<span class=MsoHyperlink>skeeve@eintellego.net</span>><br>
<br>
Version:<span style='font-family:"Times New Roman","serif"'> </span>
1<br>
<br>
Date:<span style='font-family:"Times New Roman","serif"'> </span>
3 February 2010<br>
<br>
<br>
1.<span style='font-family:"Times New Roman","serif"'> </span>
Introduction<br>
----------------<br>
<br>
This is a proposal to enable current APNIC account holders with existing<br>
IPv6 allocations to receive subsequent IPv6 allocations from APNIC for<br>
use in networks that are not connected to the initial IPv6 allocation.<br>
<br>
<br>
2.<span style='font-family:"Times New Roman","serif"'> </span> Summary of
current problem<br>
------------------------------<br>
<br>
An APNIC account holder with an existing /32 IPv6 allocation (or larger)<br>
is unable to deaggregate that allocation into routes smaller than a /32<br>
due to the community practice of 'filter blocking' or 'bogon lists'<br>
associated with RIR blocks which are known to have a minimum allocation<br>
size of /32 [1].<br>
<br>
An LIR may want to build a network in a separate location and provide<br>
IPv6 connectivity; however, because the LIR risks routability problems<br>
if they deaggregate, they cannot use a subset of their initial<br>
allocation in the new location.<br>
<br>
For example:<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
An ISP has a /32 allocation which they announce via an upstream<br>
<span style='font-family:"Times New Roman","serif"'> </span>
in New Zealand.<span style='font-family:"Times New Roman","serif"'> </span>
The ISP wants to build a new network in Singapore.<br>
<span style='font-family:"Times New Roman","serif"'> </span>
The ISP's new network in Singapore is not connected to the existing<br>
<span style='font-family:"Times New Roman","serif"'> </span>
New Zealand network and the ISP is using a local transit provider<br>
<span style='font-family:"Times New Roman","serif"'> </span>
to obtain dual stacked connectivity.<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
If the network was using IPv4 addresses, the ISP would usually<br>
<span style='font-family:"Times New Roman","serif"'> </span>
be able to deaggregate their allocation and announce one part of<br>
<span style='font-family:"Times New Roman","serif"'> </span>
the deaggregated range to the local transit provider.<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
In IPv6, however, this is not possible due to 'community filtering'<br>
<span style='font-family:"Times New Roman","serif"'> </span>
on ranges smaller than a /32.<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
Such a filter may look like the following:<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
This above statement in the IPv6 BGP filter recommendations would<br>
<span style='font-family:"Times New Roman","serif"'> </span>
cause any announcements by an ISP which had an allocation,<br>
<span style='font-family:"Times New Roman","serif"'> </span>
such as 2400:0000::/32, to announce smaller routes from that block,<br>
<span style='font-family:"Times New Roman","serif"'> </span>
such as multiple /35s for example, to be filtered.<span style='font-family:
"Times New Roman","serif"'> </span> In a default<br>
<span style='font-family:"Times New Roman","serif"'> </span>
free situation, connectivity to the ISP would be problematic.<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
Instead, the ISP needs to obtain a new /32 allocation to be able to<br>
<span style='font-family:"Times New Roman","serif"'> </span>
have IPv6 connectivity in the new location with an independent<br>
<span style='font-family:"Times New Roman","serif"'> </span>
(from their primary network) transit provider.<br>
<br>
<br>
3.<span style='font-family:"Times New Roman","serif"'> </span> Situation
in other RIRs<br>
---------------------------<br>
<br>
AfriNIC, ARIN, LACNIC and RIPE currently have no similar policies or<br>
proposals. However, ARIN mailing lists are presently discussing this<br>
situation and there seems to be significant support.<br>
<br>
<br>
4.<span style='font-family:"Times New Roman","serif"'> </span> Details of
the proposal<br>
---------------------------<br>
<br>
4.1 It is proposed that alternative criteria be added to the subsequent<br>
<span style='font-family:"Times New Roman","serif"'> </span>
IPv6 allocation policy [2] to allow current APNIC account holders<br>
<span style='font-family:"Times New Roman","serif"'> </span>
with networks in multiple locations but without a connecting<br>
<span style='font-family:"Times New Roman","serif"'> </span>
infrastructure to obtain IPv6 resources for each location.<br>
<br>
4.2 To qualify for subsequent IPv6 allocations under the proposed<br>
<span style='font-family:"Times New Roman","serif"'> </span>
alternative criteria, account holders must:<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Be a current APNIC account holder with an existing IPv6<br>
<span style='font-family:"Times New Roman","serif"'> </span>
allocation<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Be announcing its existing IPv6 allocation<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Demonstrate that the LIR has additional networks that are not<br>
<span style='font-family:"Times New Roman","serif"'> </span>
connected to the network announcing its existing IPv6 allocation<br>
<br>
<br>
5.<span style='font-family:"Times New Roman","serif"'> </span> Advantages
and disadvantages of the proposal<br>
------------------------------------------------<br>
<br>
5.1 Advantages<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- This proposal enables current APNIC account holders to avoid<br>
<span style='font-family:"Times New Roman","serif"'> </span>
problematic network design issues and policy issues related to<br>
<span style='font-family:"Times New Roman","serif"'> </span>
deaggregation.<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- Current APNIC account holders will be able to acquire resources<br>
<span style='font-family:"Times New Roman","serif"'> </span>
and announce them separately to transit providers in disparate<br>
<span style='font-family:"Times New Roman","serif"'> </span>
locations.<br>
<br>
<br>
5.2 Disadvantages<br>
<br>
<span style='font-family:"Times New Roman","serif"'> </span>
- This proposal could cause faster consumption of IPv6 address<br>
<span style='font-family:"Times New Roman","serif"'> </span>
space. However, given the size of the total IPv6 pool, the author<br>
<span style='font-family:"Times New Roman","serif"'> </span>
of this proposal does not see this as a significant issue.<br>
<br>
<br>
6.<span style='font-family:"Times New Roman","serif"'> </span> Effect on
APNIC members<br>
---------------------------<br>
<br>
APNIC members would be able to build networks in separate locations and<br>
obtain local IPv6 connectivity and announce their own resources.<br>
<br>
<br>
7.<span style='font-family:"Times New Roman","serif"'> </span> Effect on
NIRs<br>
------------------<br>
<br>
The proposal allows for NIRs to have the choice as to when to adopt this<br>
policy for their members.<br>
<br>
<br>
8.<span style='font-family:"Times New Roman","serif"'> </span>
References<br>
---------------<br>
<br>
[1] For example, see "IPv6 BGP filter recommendations"<br>
<span style='font-family:"Times New Roman","serif"'> </span>
<span class=MsoHyperlink>http://www.space.net/~gert/RIPE/ipv6-filters.html</span><br>
<br>
[2] See section 5.2, "Subsequent Allocation Section" in "IPv6
Address<br>
<span style='font-family:"Times New Roman","serif"'> </span>
Allocation and Assignment Policy"<br>
<span style='font-family:"Times New Roman","serif"'> </span>
<span class=MsoHyperlink>http://www.apnic.net/policy/ipv6-address-policy#5.2</span><br>
_______________________________________________<o:p></o:p></p>
</div>
</div>
</body>
</html>