[arin-ppml] SWIPs & IPv6
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
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
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
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