[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

Scott Leibrand scottleibrand at gmail.com
Wed Jul 19 14:12:09 EDT 2017


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.

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".

-Scott

On Wed, Jul 12, 2017 at 1:20 AM, <theone at uneedus.com> wrote:

> 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:
>
> 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.
>
> 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.
>
> 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.
>
> Here is the SWIP issue:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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???
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170719/670ab583/attachment.html>


More information about the ARIN-PPML mailing list