[arin-ppml] IPv6 Non-connected networks

Michael Richardson mcr at sandelman.ca
Thu Mar 25 12:08:07 EDT 2010

>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> Personally, I would prefer to have public PI addressing for
    David> everyone. Even setting aside the global route table politics
    David> that creates, in the enterprise would there are to many
    David> auditors, risk managers, security consultants, and compliance
    David> officers, that think they need/want private
    David> addresses. Especially for PCI, HIPPA, and other private
    David> protected data. I don't want to argue with them, it will be
    David> easier and better for me to get ahead of them and provide
    David> them what they think want, but in the way I want to do it.

I think that these folks will re-evaluate their thinking once they
realize that it wasn't the NAT that protected them but the other
defenses, and that the NAT got into the way of appropriate responses.

I have a customer who is busy trying to figure out which of his thousand
VoIP ATA units is misconfiguring, and trying to direct calls to 

    David> So while I don't personally like it, some kind of tainted,
    David> not to be routed, address space will be necessary for IPv6.


    David> Can we just leave it at that and try to bring the
    David> conversation back to how we want policy in this area to work.
    David> We need to enable as many people to implement the right
    David> solution for them.  And not be arguing about what those
    David> solutions are, which one is best, and who understands them
    David> better then the other guy.

Thank you.

I don't care about ULA-R. It doesn't solve the problems I have.


I can get address space from tunnel brokers, and they often give me
reverse DNS as well, but not whois, but usually I have do something like
route that space somewhere. (i.e. keep the tunnel up). I did this at one
place where we decided that we wanted an unrouted IPv6 management
network, because we planned to have more nodes than rfc1918 would
accomodate.  (Plan for success!)
We kept the tunnel end point up, and we used one /64 for DNS stuff,
and the rest was blackholed routed, and never connected to the
management network.
Yes, you could see our management infrastructure in public reverse DNS.
I can't tell you how much time our operations people saved by being able
to just read logs and not have to have endless cheat sheets around to
map hex numbers, and the like.  (This is a company that had otherwise
given up on DNS for all internal things, because, they could never
configure all the machines to talk to the right DNS servers...)

Tunnels can reclaim address space.


I have always liked 6to4 addressing.  If you have some IPv4, you have
plentiful amount of IPv6.  But there was no reverse DNS... Well, it
seems that http://6to4.nro.net now lets you populate it... I don't know
what the status of this, I recall it being proposed, but it wasn't until
December 2009 that I learnt that it been done.  I don't know if it will
My whois client is smart enough to do a query on the IPv4 block when
given a 6to4 network.  This is almost good enough: it's good enough for
anyone who has a /29 SWIP'ed to get what they want, and recent policy
changes mean that I think it could be good enough for everyone, even the
smallest mom+pop enterprise on commodity DSL w/static-IP, if the
commodity DSL providers would SWIP.

6to4 reclaims IPv6 address space when it recovers IPv4 space.
I don't know what 6to4.nro.net will do when someone new comes along in
the same address space. I think they just get the new reverse.


The major reason for this over ULA-R is to get reverse DNS and whois.
If there isn't that, then forget it.  Just use ULA-R.

ULA can be reclaimed if the policy says so.

"tainted" GUA.

My feeling is that this is better than ULA-C only from the point of view
of ARIN.   ARIN can do this without cooperation of any other body.
I really don't think anyone is going to start with the wrong kind of
block and want it converted.   Due to fact that we write addressing
policy as a work around for allocating DFZ routing slots,  I don't see
how "tainted" GUA can be allocated for any significant amount less than

$1250 initial fee really is a problem for many organizations.
      In small organizations because it's expensive.  In big
      organizations because it causes an addititional level of 
$1250 buys you high-end rack-mounted NAT device, and I'll bet it will
      do NAT66 very soon.  Combine that with PA or 6to4 and ULA-R,
      and you have a repeat of mid-1990s coconut security.

GUA is obviously reclaimable.

    David> - The amount of space an end-user organization qualifies for
    David> should be based on the number of sites they have

Do you mean, the number of allocations, or the size of the allocations?

    David> Personally, I'm agnostic if we do this with FC00::/8 or
    David> within Global Unicast in 2000::/3. But, if we don't use
    David> FC00::/8 we shouldn't call it ULA-C.  However, a rose or a
    David> cow patty by any other name...  Remember we already have
    David> 6.10.2 Micro-allocations for Internal Infrastructure, this is
    David> basically the same thing.

Everyone has understood that micro-allocation was for IXs. 

    David> People ask what the killer app for IPv6 is, I believe it is
    David> long-term cost reduction of network operations, IPv4 networks
    David> are expensive to operate.  Ask the big cable providers why
    David> they want to go to IPv6, it is to reduce there cost of
    David> network operation.  As a large scale enterprise network
    David> operator I want to reduce our cost of network
    David> operations. Like eliminating (or avoiding, in our specific
    David> case) the cost of NAT, /64 subnets in IPv6 will eliminate a
    David> whole class of network management costs, managing subnets in
    David> IPv4 is an expensive pain in the backside, especially at our
    David> scale 2500+ subnets.

I concur 200%.

I think the AC needs to tell come to some consensus about "tainted"GUA,
or ULA-C.  I think that the IETF will cooperate if it's ULA-C.

]       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