Why not RIO? (Re: Geoff on IPv4 Exhaustion)

[Jussi Peltola]

On Sun, Nov 20, 2011 at 05:23:57PM +1300, Brian E Carpenter wrote:
> When you write "hosts'" do you mean that you need to configure
> each individual host's routing information *separately*?

Not necessarily different for each host. Different for groups of hosts
in the same subnet? Most definitely.
 
> If the answer is yes, what is the reason use case for needing to configure
> each host separately?
> 
> If the answer is no, why can't RA/RIO (RFC 4191) be used?

1. Let's assume I have installed a new router. For testing, I want to point
some of hosts towards it, while not endangering the rest of the hosts.

How can I achieve this with RA? (A definite pro for RA is the ability to
immediately remove the routes to the new router if things go bad, at
least if the end-hosts are working correctly.)

Maybe I just want a clean cut-over in a SMB LAN? Currently I can just
put in a new DSL modem from another provider with DHCPv4 and disable
DHCP on the old one, and the hosts will eventually renew their lease and
jump on the new one (with a non-overlapping dhcp pool).  With the
proposed ipv6 scheme of RAs and multiple prefixes without NAT, there is
a good chance of hitting the wrong ISP and uRPF dropping packets. I see
it as very beneficial to get one cohesive configuration from one DHCP
server, including the default route, instead of a mash-up from multiple
sources.

Sure, nobody cares about ugly SMB LANs. There are millions and millions
of them out there, but they're not sexy so why care about them?

2. I have seen lots of networks with flat L2 networks spanning multiple
buildings. They do not want to change that for various reasons. The
interconnect is usually too small.

Let's assume they have internet connectivity in building A and B. Both
have routers, with two VRRP addresses and tracking so that A is master
of vrrp ip A and B is master of vrrp ip B. Clients' default routes point
to A in building A and to B in building B. This is not a very beautiful
setup, but I have seen it used and perceived inelegance of some use
cases is not a reason to not implement a feature. With RAs this is not
easily possible, to point building A to router A you would need to
filter RAs between buildings but that would break the fail-over.

3. You have 2 completely different networks that for some reason or just
by accident are in the same L2 segment. You do not want the hosts
pointing at the wrong default router. This is common when cleaning up a
flat jungle LAN, you first split things into subnets and then split them
to VLANs. With DHCP I can be reasonably sure that the network will work
when split into VLANs if it worked with the separate subnets on the same
VLAN. With RAs, I'd not be so sure.

The failure mode with RAs leaking between different networks is uRPF
blackholes and acute pain. With DHCP you either have no 2-way
communication so nothing happens, or you get all your config (including
the default gw) from some of the networks and it should work. If you
have all static leases, nobody notices.

4. You have devices, like printers, that you do not want communicating
outside the subnet at all, so you want to config them without a default
router. Kind of silly, but I have seen this policy in the real world. A
knob in the printer to not accept RAs is no help, you need to enable it
by walking to the printer and walk again to disable it if you decide to
not do it anymore.

5. For load sharing, you may just want to point some hosts on one router
and others to another one. Again, maybe not elegant but this happens.

6. Legacy protocols that require shared L2 are another argument for 3.
Protocol VLANs et al exist, but there are legacy applications requiring
IP broadcasts. Why would I rework the whole network to introduce IPv6?
My customers would probably not want to pay the costs involved with
that.

I just came across a customer with a 286 DOS file server and NetBEUI for
an industrial embedded system. The 286 and the flat lan is not going to
go anywhere any time soon. His switches do not support VLANs and his
voip phones receive DHCP service that points them to the voip provider's
firewall, which has a route to the voip provider's rfc1918 space, while
his workstations receive DHCP leases that point to another firewall that
is connected to a DSL line. How will this work in an ipv6-only world,
with RAs? The voip provider's firewall is not accessible for
configuration, but it only gives out DHCPv4 leases to phones. No static
conf of workstations of phones is desired.

(Yes, what an ugly network. Welcome to the real world.)

7. I have a laptop that I want to use for PXE installation. Let's
pretened that PXE is possible on IPv6...

I configure static leases for the hosts I want to install, and because
the network said hosts are in is connected to the rest of the world with
a ludicrously expensive and slow VPLS DSL line, I set my laptop as their
default router, with the business park's 11n guest wlan as its uplink. I
want to be sure nobody catches me doing this - with DHCPv4 I can be
reasonably sure no other hosts are disturbed. How to do this with RAs?
The PXE image I am booting is a fully automagic installer, and the hosts
are physically placed so that it is not an option to connect them
directly to the laptop. After the hosts have booted the PXE installer I
stop the dhcpd on my laptop, so they will reboot and get on the network
they normally live in.

The PXE image is ready-made to accept RAs and download stuff from
outside the local subnet. I don't have time to modify it. DHCPv4 allows
me to do what I need in the time that I have.

> Precise answers to these questions will help to make progress
> in the IETF discussion on this over the next few days.
 
The world is not elegant nor a green field. Very different hosts in the
same broadcast domain exist and will continue to exist. If IPv6
standards require you to jump through hoops to get IPv6 to them, it will
take a very long time till they get IPv6.

To think that all routers in a subnet are equal and that you do not need
per-host config would be incredibly naive 20 years ago, and it is
completely ridiculous in 2011.

The customers in this e-mail are mash-ups of real ones. The scenarios
are real.

Jussi Peltola