[arin-ppml] IPv4 SWIP requirements (?)

[William Herrin]

On Mon, Jun 19, 2017 at 1:37 PM, David R Huberman <daveid at panix.com> wrote:

> Based on comments so far, most agree that a /48 should be SWIP'ed since it
>> is routable on the internet, and since so far the majority seems to think
>> that /56 is small enough to not require SWIP, this leaves 7 choices of /49
>> to /55 to set the limit for SWIP in the Draft.
>>
>
> I think that when we consider SWIP boundaries, we should take into account
> strictly technical considerations, and not arbitrary ones.  I think the
> argument for requiring a /48 or larger to be SWIPed is well-grounded in
> network engineering practices.  I'm not sure I understand the technical
> argument for anything smaller than a /48 being mandatory.
>

Hi David,

The obvious technical argument against Nibble "or larger" is that it
encourages assignment on non-niblle boundaries. If /56 requires SWIP, the
ISP has reason to assign /57 instead of /56.  That makes IPv6 assignment as
messy as IPv4. If instead /55 requires SWIP, the likely ISP default value
becomes /56, a good nibble-boundary choice. A policy which starts requiring
SWIP at Nibble+1 implicitly encourages the ISP to set their default
assignment size at a nibble boundary which is well-grounded in network
engineering practices

So first and foremost it is technologically correct to set the SWIP
boundary to start at "larger than Nibble" or "Nibble+1 or larger."

Since "larger than /48" and "/47 or larger" are ruled out by /48's
independent routability (also a technical consideration) and /64 is ruled
out for preventing the intended end-user  IPv6 routing ability (also a
technical consideration), that leaves "larger than" /52, /56 and /60 as the
only -technically reasonable- options.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170619/1ff0db01/attachment.htm>