Re: Dual stack IPv6 for IPv4 depletion

[Owen DeLong <owen () delong com>]

Because vendor pressure depends on a userbase that knows enough to demand fixes.

Simple fact is that if most ISPs deploy degraded services, vendors will code to the lowest common denominator of that 
degraded service and we’ll all be forced to live within those limitations in the products we receive.

This is already evident in the IPv4 world. Even though my TiVO is 100% reachable from the internet, I can’t use any of 
TiVO’s 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.

Can you offer one valid reason not to give residential users /48s? Any benefit whatsoever?

Owen

> On Jul 9, 2015, at 14:51 , Naslund, Steve <SNaslund () medline com> wrote:
>
> So, why not demand that firmware accepts ANY mask length just like VLSM v4.  I don't see what possible difference it 
> will make if it is a /56 or /48 and I don't think you should make ANY assumption based on either of those being 
> correct for any particular application.  An assumption you make today is only applicable to your network not mine, it 
> has no certainty of permanence at all.  If one of my software engineers came to me and asked I would tell them they 
> need to handle all possible mask lengths...period.  Even if they are not in common use today, if its legal under the 
> v6 spec then you should expect to support it.   Not engineering for change is how we end up with software that won't 
> handle a 2xxx year or a leap second.
>
> If a vendor decides to code something like the ff02:: scoping into their systems in a way that can't easily change 
> then it is at their own risk.  Would it be very difficult to change that depending on the DHCP-PD response you got?  
> Why do you want to be the guy to make the bad assumption instead of them?  That's what you are doing in the /56 vs 
> /48 argument is it not?  A little early in the IPv6 game to be making permanent rules on allocation sizes for future 
> generations and hard coding them don't you think?
>
> All of statements you make regarding "enable some development" and "reasonable end-site boundary" are the network 
> equivalents of the "no one will need more that 640k of RAM" and "32 bits will be more addresses than we ever need"
>
> As far as opening up my mind a bit how about opening your mind and demanding that IPv6 compatibility means accepting 
> ALL possible allocation lengths.
>
>
> Steven Naslund
> Chicago IL
>
> > Sigh…
> >
> > Home gateways are an application in this context. How the firmware gets written in those things will be affected.
> >
> > Further, applications do care about things like “Can I assume that every home is reachable in its entirety via a 
> > packet to ff02::<group>?” which is, for example, already baked into many products as the current mDNS default scope.
> >
> > SSDPv6 also seems to default to ff02:: scoping.
> >
> > Whether or not applications come into existence that can take advantage of diverse topology in the home will depend 
> > entirely on whether or not we make diverse topology possible going forward.
> >
> > /56 will enable some development in this area, but it will hinder several potential areas of exploration.
> >
> > /48 is a reasonable end-site boundary. It allows enough flexibility for dynamic topologies while still leaving 
> > enough prefix space to have lots of extra room for sparse allocations and everything else.
> >
> > So, instead of focusing on the narrowest possible definition of “application” by todays terms, try opening your mind 
> > just a little bit and recognize that anything that requires software and interacts with the network in any way is a 
> > > better definition of application in this context.
> >
> > Owen