<div dir="ltr">As I understand it, if the ISP assigned you a /48 and individually routed the /64s for you, they would only have to create a single SWIP entry for the /48, and the street address of your central location (or your administrative HQ, if different) would be perfectly appropriate for that SWIP. <div><br></div><div>I agree that eliminating the need to SWIP /64s and residential /56s would be good, and still support the general idea of this proposal (and most of the variations that have been proposed thus far). However, I think this use case does highlight the need to make sure that we *do* consider requiring SWIP of /48 aggregates like the one your ISP is assigning you, even if they're routing the pieces of that aggregate independently to different "sites".</div><div><br></div><div>-Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 1:20 AM,  <span dir="ltr"><<a href="mailto:theone@uneedus.com" target="_blank">theone@uneedus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to give an example of why the current /64 or more rule for IPv6 SWIP vs IPv4 is an issue for a project I am working on:<br>
<br>
I am working on a project to enable public IPv6 on Public Transit busses. Currently we have a public V4 address assigned by the winner of a State Government Contract with a major wireless provider used for each bus in the fleet, which is in excess of 1000 busses.  Originally we used this connection only for administrative use, such as communicating the real time location of each bus back to headquarters and access to cameras and reporting in an emergency.  In the last few months, we added an additional RFC1918 IPv4 private address subnet so that a wireless access point for public wifi is available on each bus.  In order to address the administrative equipment from headquarters, we must have a static address to connect to.<br>
<br>
Because it is a State Government contract, the major wireless provider still has to provide us public, static IPv4 addresses until the end of this contract, which is Sept 30, 2018.  This major provider has publiclly announced that they will no longer provide Static IPv4 addresses to anyone, and we have been told they will not bid on the next contract if that contract would require an option to assign static v4 addresses like the current contract, as they are leasing the IPv4 addresses we are using. We have been told if we want Static assignments, they now must be only IPv6, and they will provide up to a /56 for each bus out of a /48 of their space assigned to all our busses.<br>
<br>
Thus, there is a plan to put the administrative parts of the busses onto IPv6 before the end of the contract. We wont care if the carrier v4 address is static, public, or even CGnat, as it would then only be only used for the public v4 wifi.  We might also consider a PI v6 allocation from ARIN if they will route it to us.  This would keep us from having to renumber if the State Contract provider changes, and a /48 of space would be plenty for all v6 use.<br>
<br>
Here is the SWIP issue:<br>
<br>
The major provider according to the current rules must SWIP each static "Serving site"(NRPM 2.14), which in this case is a transit bus.  Each bus is its own account with the wireless provider, and will have its own static IPv6 network and IPv4 address assigned.<br>
<br>
NRPM 2.12 requires each SWIP entry must contain Street Address, City, State, and Zip Code.  How can I give a Street Address for a mobile serving site as required by NPRM 2.12?  Each bus covers 200-300 miles a day, and about 1/2 do not return to our central location during any portion of their daily trips. I am sure that the abuse address for the SWIP will attract attention because of public wifi on each bus, and our intent to enable v6 connections on each "Serving Site" (Transit Bus) including the public wifi.<br>
<br>
If the current proposal at more than a /60, or a greater amount such as more than a /56 is adopted, the wireless provider no longer has to SWIP each site (Transit Bus) just like v4. This would allow us to avoid having to SWIP each "Serving Site" as the current IPv6 rules would require and keep us legal with the policy manual.<br>
<br>
If the community comes out against relaxing the IPv6 SWIP rules, my only other choices are to hope the wireless provider will ignore the NRPM, or write another proposal to add language to 2.12 to allow mobile "Serving Sites" to be registered to a central location to avoid the street address and city problem with mobile "Serving Sites".  The wireless provider is unlikely to allow all the busses to be SWIP'ed to the Central site because they would be the one trying to explain to ARIN why 1000 networks are all registered at the same location.<br>
<br>
This was never an issue with IPv4, as each bus has only one IPv4 address, which did not trigger any SWIP requirement.  This example also shows how the different treatment of v4 and v6 affects small users of v6.<br>
<br>
I Would love to hear some input as to the issue of dealing with "Serving Sites" that are mobile (like Transit Busses), or do not have a street address assigned, like some of the rural WISP sites I work with including my own home. If I decided to put a non residental circuit there that includes any amount of IPv6, it would not be able to be SWIP'ed as I have no Street Address and the rules do not allow the field to be left blank. What then???<span class="im HOEnZb"><br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div>