Re: Dual stack IPv6 for IPv4 depletion

[Mark Andrews <marka () isc org>]

In message <9578293AE169674F9A048B2BC9A081B401C7097D2E () MUNPRDMBXA1 medline com>
, "Naslund, Steve" writes:
> > Subject: Re: Dual stack IPv6 for IPv4 depletion
> >
> > Because vendor pressure depends on a userbase that knows enough to 
> demand fixes.
>
> No vendor pressure is dependent on people buying their stuff.  Don't send 
> that CPE to your user if it does not meet your standards.  If their stuff 
> breaks because of shortsighted coding to bad for them.  I am not going to 
> be the guy to build in stupid limitations today to save a few minutes of 
> coding for some lazy hardware vendor.
>
> > Simple fact is that if most ISPs deploy degraded services, vendors will 
> code to the lowest common denominator of that degraded service and well 
> all be forced to live within those limitations in the products we receive.
> >
>
> Why would you think so?  Did your IPv4 router not accept a /8 netmask 
> even though there was very little chance you would get one?  I know most 
> of my programmers are trained to anticipate all of the possible options 
> for an input.  Sometimes this is hard to define but with IPv6 it is 
> clearly in the specification.
>
> Would you consider an ISP that hands out /56s to be "degraded"?  Most 
> users wouldn't know the difference and if you offered the /48 on request 
> (or even better automatically on depletion of the /56) what would be 
> degraded?

Because ISP's have a track record of not listening to user requests.

Getting IPv6 delivered is a prime example.  Some of us have been
requesting it from our ISP's for well over a decade now and they
are still yet to deliver.

Some of us have requested that SUBMIT be enabled on their outgoing
mail server for just as long, a simple 1 line fix in the mail server
config.  No, webmail is not a acceptable alternative.

It's likely to take as long to get them to increase the allocation
from a /56 to a /48 despite it being a 1 word fix in a config.
Getting that one word change will not be as easy as ring up customer
support and saying "Can you please increase the number of subnets
returned to a prefix delegation request?" and getting "Yes" as the
answer.

> > This is already evident in the IPv4 world. Even though my TiVO is 100% 
> reachable from the internet, I cant use any of TiVOs applications to 
> access it directly, I have to work through their proxy servers that 
> depend on periodic >polling from my devices to work because they assume 
> everyone is stuck behind NAT.
> >
>
> That would be Tivo's fault wouldn't it.  It would be trivially simple for 
> them to know if they were behind a NAT so I am guessing they force you 
> through their proxy for other purposes.  Should we re-engineer the way IP 
> works so that Tivo can write crap code?  Should we limit all future v6 
> users today so that crap CPE works now?

No.  It is ISP's and CPE vendors faults for stalling on IPv6 for
well over a decade.  If we all had IPv6 in the home a decade ago
Tivo could have designed for a reachable device rather than one
that had to polled due to there being no IPv6 in the home and IPv4
addresses changing all the time due to there not being enouhg of
them and ISP's having to juggle them.  Tivo added IP support in
2006.  Windows XP already had IPv6 support when Tivo shipped their
2nd gen box.

A Tivo box is a in-home server.  That requires stable addressability
which IPv6 (RFC 2460) can deliver, using address blocks assigned
from the ISP using PD (RFC 3633).  With IPv6 it could register its
address in the global DNS using a TSIG (RFC 2845) signed UPDATE
(RFC 2136) requests just the way your Mac can do today.

All of these RFC's existed when the 2nd Gen Tivo was designed.  What
didn't exist was ISP's delivering IPv6 to the home customer.  What
Tivo had to work with was 99.9% of the user base behind a NAT with
no address stablility.  How would you design your Tivo?

> > Can you offer one valid reason not to give residential users /48s? Any 
> benefit whatsoever?
> >
>
> I never said that there was a valid reason not to use /48s or /56s or 
> whatever prefix you like.  What I am saying is don't force that decision 
> on anyone today.  IPv6 does not force the use of any particular prefix 
> length for an end user, why should you?  Why do we all have to use the 
> same length anyways?
>
> > Owen
>
>
> Steven Naslund
> Chicago IL

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org