[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-narten-ipv6-3177bis-48boundary-02.txt



Hi Iljitsch,

On Fri, 14 Jul 2006 09:54:54 -0400
Iljitsch van Beijnum <iljitsch@muada.com> wrote:

> I agree, except that /56 is still too large for small / home  
> networks, and I fear that ISPs will want to skimp even more and give  
> out /64s. 

I'd think the market would sort that out very quickly - if I'm choosing
an ISP for my home, and one gives out /56s, and another gives out a /64
(and then charges more for that /64 because they also are having to
manage the option of providing /56s and /48s), then I'm going to go for
the option that is likely to cause me the least potential
administrative hassle in the future. I think it is inconceivable I'd
every use up 256 subnets at home (and hey, I'm a networking person, so
I'd probably willing to spend time getting around this limitation if I
hit it by going to /80s for my subnets), so the /56 option is more
attractive as I'd never hit it. Even people who don't understand the
technical differences will pursue the /56 option, because people will
always go for more "bangs per buck", even if they're unsure of exactly
what the "bangs" are, as long as somebody tells them more "bangs" are
useful to have even if you don't ever use them.

The /48 option also is provides an "inconceivable" subnet limit. What
it does though, when compared with the /56 option, is pushes that
boundary of inconceivability to be inclusive of almost every potential
IPv6 user out there, elminating the costs of dealing with running out
of subnets for almost everybody. For those who are likely to hit a
subnet limitation with a /48, I'm pretty sure they'll be smart enough to
recognise that from day one, and request the enough address space
they'll need before they need it. 

> And as I said before, individual /64s aren't all that  
> useful in practice.
> 
> > However, I think going to variable sized allocations for end-sites is
> > throwing the baby out with the bathwater. It increases addressing
> > administration costs, is much harder to understand for most network
> > administrators, and is much more error prone.
> 
> Agree. There is also the issue that DNS reverse mapping delegations  
> are easier on 4-bit boundaries, although this isn't a big enough  
> issue to be show stopper on its own.

True. Simplicity in DNS reverse mapping is another benefit of "throwing
addressing bits" at the problem. 

Regards,
Mark.