Private use of non-RFC1918 IP space

I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like

1. How do we migrate to a IPv6 stack on all servers and I am talking about the
   thousands of servers that exist on peoples network that run SaaS,
    Financial/Banking systems.

2. How do we make old applications speak IPv6? There are some old back-end systems
   that run core functions for many businesses out there that don't really have any
   upgrade path and I don't think people are thinking about this.

From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network.

Zaid

Zaid Ali wrote:

I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like

1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems.
  

Just upgrade your load balancer (or request a feature from your load balancer company) to map an external IPv6 address to a pool of IPv4 servers. Problem solved.

2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any
   upgrade path and I don't think people are thinking about this.
  

Continue to run IPv4 internally for this application. There's no logical reason that IPv4 can't continue to coexist for decades. Heck, people still run IPX, right?

-Paul

It's not just technical. Companies are reluctant to migrate to an IP address
owned by an ISP. We are one of those companies. If and when it is easy for us
to apply and receive our own Ipv6 address space, we will look at deploying
ipv6, but not until then. That's not a technical issue, but rather a business
decision, and it's not going to change. We aren't depending our network
resources on an external third-party, especially given their track record.

Matthew Huff.vcf (1.57 KB)

Yes we all go to NANOG meetings and talk about these solutions but the change has to come from within. its not just a technical solution. There has to be motivation and incentive for people to make this change.

Zaid

Matthew Huff wrote:

It's not just technical. Companies are reluctant to migrate to an IP address
owned by an ISP. We are one of those companies. If and when it is easy for us
to apply and receive our own Ipv6 address space, [..]

Because like, ARIN wasn't the first RIR to provide that possibility.

http://www.arin.net/registration/guidelines/ipv6_assignment.html

I assume you will have IPv6 next week now?

Greets,
Jeroen

Renumbering will happen. Be prepared or cry louder when it happens. DNS was
invented for this, and v4 PA space is functionally equivalent to v6 here.

Getting PI space only pushes the inevitable a bit, while lessening the
incentives to DTRT wrt IP address mobility.

DNS is great, but there is plenty of stuff to change that doesn't use DNS (ACLS, etc...). The point is, why should we go through the pain of renumbering, and have to do it everytime our relationship with our ISP changes? We aren't going to go there. It isn't renumbering that's the problem, the problem is that it being tied to an external company.

Matthew Huff.vcf (1.57 KB)

With new dual-stack border devices people will be able to move bit by bit, and there is no real reason to have to run around and change everything that you have internally. These will change and update over time. These internal applications aren't running on public IP addresses anyway.

...Skeeve

The problem with that solution mainly being that the application itself
   still needs some sort of intelligence as well as the border device
   potentially doing L7 operations (header insertion/etc.) - unless you're
   OK with generally losing all information about the source of incoming
   traffic at the backend (except for looking at NAT tables...)
   -Dave
   Skeeve Stevens wrote:

With new dual-stack border devices people will be able to move bit by bit, and t
here is no real reason to have to run around and change everything that you have
internally. These will change and update over time. These internal applicatio
ns aren't running on public IP addresses anyway.

...Skeeve

Owned by an ISP? It isn't much different than it is now.

As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this.

Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap.

I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now.

If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above.... I wonder if that will start a flame war *puts on fire suit*.

...Skeeve

* never say never!
# http://www.iana.org/assignments/ipv6-unicast-address-assignments

See my other email.

You don't need to use a providers range.

...Skeeve

And for those kinds of applications, yell at your vendors to come up with a solution.

They say that there is about 2 years of ipv4 left. Then we’re screwed. If people sit with their thumbs up their asses now, and are not out planning budgets and migration strategies, they will be caught when they want to do network expansions.

Note… the running out of IPv4 will NOT effect your current operations in any way. Your providers transit will (or already has) become dual stack, and you will continue to be able to talk to the internet as a whole unless native v6 only content starts to appear, which it will and then problems will appear.

This situation will be able to go on for years without your changing anything….. unless you want these applications to keep communicating with the ever growing internet on ipv6… and if you do, plan for it… decide if you’re going to do it now, in a year, or in 10 years and how you want to look to your shareholders or stakeholders… because eventually, they will ask… they may not want to pay for it just now… but there is a lot of things you can do before you have to start paying real money for things.

- Getting your assignment/allocation

- Developing your documentation/plan of how it will be assigned internally

- Start to identify what parts of your infrastructure will not cope (everyone will need to use NAT-PT internally for some 10 years or more)

- Start talking to your hardware and software vendors about v6 and understanding their product roadmaps, timelines and so on.

With all this, when it becomes inevitable you won’t have to suddenly do a ton of work…. Or you could buy ‘Migrating my corporate network to IPv6 for Dummies’

…Skeeve

Skeeve Stevens wrote:

Owned by an ISP? It isn't much different than it is now.

As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this.

Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap.

I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now.

  RFC4193 - Unique Local IPv6 Unicast Addresses

http://www.iana.org/assignments/ipv6-address-space
FC00::/7 Unique Local Unicast [RFC4193]

  ..maybe they should have called it RFC1918 for IPv6.

FWIW, 2001:0DB8::/32 was allocated by APNIC. Not quite the same as being an RFC/IANA delegated/reserved netblock.

  --heather

Skeeve Stevens wrote:
[please fix your line length, my screen is still not a 100"]

Owned by an ISP? It isn't much different than it is now.

As long as you are multi-homed you can get a small allocation (/48),
APNIC and ARIN have procedures for this.

Yes, you have to pay for it, but the addresses will be yours, unlike
the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share
and hope we never interconnect/overlap.

I can't find a RFC1918 equivalent for v6 with the exception of
2001:0DB8::/32# which is the ranges that has been assigned for
documentation use and is considered to NEVER be routable. In that /32
are 65536 /48's... way more than the RFC1918 we have now.

Documentation is exactly that: Documentation.
Do not EVER use that in a real box.

If you need 'RFC1918 alike' space then go for ULA (RFC4193).
Also see IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker for a semi-registered
version of that. If you want "guaranteed unique" then go to a RIR.

If I was going to build a v6 network right now, that was purely
private and never* going to hit the internet, and I could not
afford to be a NIC member or pay the fees... then I would be using
the ranges above.... I wonder if that will start a flame war *puts on

fire suit*.

Google goes straight through that suit, I suggest you use it and read up
on IPv6. Even the Wikipedia entry contains this information.
google(rfc1918 ipv6) or Private network - Wikipedia

Greets,
Jeroen

Owned by an ISP? It isn't much different than it is now.

As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this.

To clarify, you can get whatever size assignment you need, but, the default
unless you request larger and can justify it is a /48. To put this in perspective,
a /48 is 65536*4billion*the total IPv4 address space. Further, it's enough space
for 65,536 subnets with 64 bit host addresses. Likely, this is enough for most
end-user organizations, but, if you are part of an organization that needs more,
you can get it simply by justifying your additional needs.

Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap.

In the ARIN region, the end-user annual fees are quite low. I don't see this as
a significant barrier to entry to most end-user organizations.

I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now.

There is the ULA-Random space, but, I'm not sure if that got ratified or was
rescinded. I really don't see a need for RFC-1918 in
the IPv6 world. RFC-1918 was intended to solve a problem with a shortage
of address space by allowing disparate private networks to recycle the same
numbers behind NAT or for use on non-connected networks. There is no
such shortage in IPv6. I think it is wiser to number non-connected IPv6 networks
from valid unique addresses since there is no shortage.

If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above.... I wonder if that will start a flame war *puts on fire suit*.

I don't know what the APNIC fees and membership requirements are.
However, in the ARIN region, you do not need to be a member to get
address space. The renewal fee for end-user space is $100/year.
If you can't afford $100/year, how are you staying connected to the
network or paying to power your equipment?

Owen

ULA is useful for organisations that cannot get an RIR allocation/assignment, so are likely to need to re-number.

If they number on ULA *in addition to* whatever space their ISP gives them, they do not need to alter any internal DNS, ACLs, etc. etc. if/when they re-number. An easy example of a good use for ULA might be the internal recursive DNS server addresses that the DHCPv6 server hands out.

If they are so inclined, they might even re-number dynamically if they get their prefix using PD.

Owen DeLong wrote:

...
I don't know what the APNIC fees and membership requirements are.

A succinct summary, see below !

However, in the ARIN region, you do not need to be a member to get
address space. The renewal fee for end-user space is $100/year.
If you can't afford $100/year, how are you staying connected to the
network or paying to power your equipment?

APNIC fees are an order of magnitude (or more) higher !

http://www.apnic.net/member/feesinfo.html#non_mem_fee
ftp://ftp.apnic.net/apnic/docs/non-member-fees-2008 (APNIC-118)

I quote from APNIC-118 :

A host address in IPv4 is defined as a /32 and a site address
in IPv6 is defined a /48.

The initial fee for an assignment or allocation of IP
addresses is AU$1.27 per host or site address, with a minimum
fee of AU$10,384.

After the first year of the initial assignment or allocation,
there is an annual registration fee is AU$0.127 per host or
site address, with a minimum fee of AU$1,038.40.

Exactly.....

So.. do I have to be in the US to get ARIN space? Technically space you get
is announceable anywhere in the world...
Can I just have a /32 from ARIN please and not pay the ton of money that
APNIC ask for?
I can setup a POBOX in New York if that will help? :wink:

Actually, that is an interesting question... If I have a network I am
building in the US/other locale, but I am based here, can I become an
ARIN/RIPE/etc member and get a range out of them?

...Skeeve

Skeeve Stevens wrote:

Owned by an ISP? It isn't much different than it is now.

As long as you are multi-homed you can get a small allocation (/48),
APNIC and ARIN have procedures for this.

Yes, you have to pay for it, but the addresses will be yours, unlike
the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share
and hope we never interconnect/overlap.

I can't find a RFC1918 equivalent for v6 with the exception of
2001:0DB8::/32# which is the ranges that has been assigned for
documentation use and is considered to NEVER be routable. In that
/32 are 65536 /48's... way more than the RFC1918 we have now.

FD00::/8

ula-l rfc 4139

s/4139/4193/