[arin-ppml] SWIPs & IPv6

Michael Richardson mcr at sandelman.ca
Mon Nov 30 21:44:26 EST 2009


>>>>> "Danny" == Danny McPherson <danny at tcb.net> writes:
    Danny>    I'd like to know what folks here are thinking regarding
    Danny> IPv6 and SWIPs.  In particular, a primary driver for SWIPs
    Danny> today is to enable justification of additional addresses
    Danny> (when the time comes).  SWIP data is clearly invaluable to
    Danny> network operations and security folks, as well as law
    Danny> enforcement, when investigating or dealing with various
    Danny> incidents (not to mention many other uses, as many of you
    Danny> well know).  

Uhm, I guess I really disagree.
Maybe to operators that do not take support calls (in particular support
calls from other ISPs), then the "primary driver for SWIPs today is to
enable justification of additional addresses".

But, to the rest of us, SWIP data is not just "clearly invaluable", it's
critical to all manner of internal and external support, both for
enterprises (me), and ISPs (sometimes me). 

But, certainly if it's the case that updating SWIP data is just a chore
necessary to get more address space, that certainly explains why some
ISPs (near me) have little interest in keeping it update, or in doing
proper reverse DNS.

    Danny> basis.  Furthermore, while development of an RPKI is
    Danny> underway, it really only deals with certification of routed
    Danny> number spaces (as currently specified).  While I _think we
    Danny> don't want all subsequent assignment/allocation data in the
    Danny> RPKI, I'm worried we won't have it anywhere with IPv6 -- or
    Danny> in many different places and formats.  I suspect at least a
    Danny> BCP (some form, some where) and some community guidance is in
    Danny> order along these lines (i.e., SWIP-esque data is a must to
    Danny> some reasonable level of granularity), I'd like to see what
    Danny> folks here are thinking along these lines..  If I've missed
    Danny> this discussion here (or in other forums) references welcome,
    Danny> a cursory search yields nothing expressly related to this
    Danny> topic.  

1) So, I think you are saying that in IPv6 land, there will be little
   reason to update delegated SWIP data: Most delegations won't have
   routing different than their aggregate, and therefore won't an RPKI
   entry either.  

2) You are also saying that all address space that everyone sees will, if 
   you can see, it, be routable. 


WRT (1): I think you are probably right.  I wish I could point to a BCP
    that told ISPs what they are expected to do.  
    For instance, how many support RFC2317 for delegation of reverse DNS?

    For me, this is one reason to support Bill Herrin's policy proposal
    103 to allocate address space in well known sizes, from well known pools.
    At least when the SWIP data is missing, one will have some idea what
    was *supposed* to happen for this block.


WRT (2): This concerns me more.  I think it is really only true for
    operators. IPv6 got too much input, I think, from clueful operators and
    backbone equipment vendors :-)

    For enterprises, the lack of local address other than ULA ones is
    a problem, in my opinion.

    One of the reasons why I dislike RFC4193 (ULA-local) addresses is
    because there is no SWIP information.  If I see a ULA somewhere that
    it does not belong, it's very hard for me to determine who it is
    supposed to belong to. 
    (It's certainly the same thing with RFC1918 addresses... and it's
    also one of the reasons why we got rid of IPv6 site-local addresses...)

I have seriously been into multiple organizations where the site to site
connectivity was not a VPN, but was outsourced to an "ISP" to "manage".
Historically, it was supposed to be run on dedicated equipment, but more
often than not, it was "virtual" (with real invoices for equipment not
bought).
Today, at least nobody pretends that the equipment isn't virtual.

Why was I there? To help determine the origin of rogue packets that
seemed to be originating from the inside.  ULAs, RFC1918s and anything
not properly SWIP'ed makes this really hard.  Unique addresses are good.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

    







More information about the ARIN-PPML mailing list