Re: [v6ops] Please review the No IPv4 draft

["Dale W. Carder" <[e-mail]>]

Thus spake George, Wes ([e-mail]) on Tue, Apr 15, 2014 at 03:24:13PM -0400:
> On 4/15/14, 11:20 AM, "Bernie Volz (volz)" <[e-mail]> wrote:
> 
> >Yeah, but we survived the transition away from these older networks
> >without significant issues and special messages on IPv4 to tell clients
> >"don't try IPX or AppleTalk or ...".
> >
> >- Bernie
> 
> Ok. Youngin’ (and cochair of Sunset4) speaking. My experience with
> networking begins after these transitions were largely complete, so I
> genuinely don’t have a good sense for what was done to “survive" this
> transition, and I’d bet Simon doesn’t either. If that’s really the right
> model,

I'm not sure it was the "right" model, but we learned a lot.

Everything in that timeframe was manually configured, although host
numbering was automatic in IPX, plus we enforced bootp/dhcp use for v4.  

There were a number of factors that came into play in our migration off 
IPX.  Every PC was dual-stack in effect.  All major applications (really 
netware, and printing) were on IPX and used SAP for discovery.  When 
these applications made it to ipv4 they also used ipv4 SLP for discovery.

However, there was no RFC 3484 for IPX/IPv4.  This meant that every PC 
(thousands) had to be visited manually and reconfigured to prefer ipv4 
over ipx.  Only then could we start the migration off of IPX.

Today we do have 3484 (or better), plus happy eyeball variants.  If we
had either then, I think the transition would have been cake, and the
migration would have been through atrophy.  

These were good sized broadcast (and collision) domains.  Each was 
typically a big hub with a /22 that fed branches on thinnet.  Our final 
push was for getting rid of SAP broadcasts.  We had them at peak probably 
around 10 or 20 kpps, which was a disaster for the shared L2 segments
and slow clients.

We got lucky on appletalk because we forced most of the issues when we 
went from localtalk to ethernet.  However, we kept gator boxes running 
as protocol translators, primarily for printing from apple OS 7 - 9 
clients.  We had hundreds of zones though, which was still horrible.  I
disabled appletalk on each router subint one at a time over the course
of a year (this was 2006!).

> Since we’ve brought up reducing junk client-sourced traffic on wireless
> networks as one of the goals of being able to tell clients to stop
> speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and
> Appletalk networks were there? (and yes that last question is mostly
> tongue-in-cheek)

These days we have thousands of AP's, with an ipv4 /17 for clients.  
However clients sending unnecessary dhcp probes is in the OK direction 
because this can be filtered on ingress at the AP, and it won't be
broadcast back out to others.  In fact we suppress ARP and other
multicast in a similar manner.  Modern enterprise wireless controller 
networks are way, way more sophisticated than their wired counterparts 
due to the management of scarce RF time.  So, I don't buy any argument
in this draft that there is a problem in this direction.  If anything,
modify dhcpv4 to do exponential backoff, but I doubt this would work
either since the clients sleep and wake up too often.

Dale