Re: v6 subnet size for DSL & leased line customers

> It's likely that the device may choose to nat when they
cannot obtain a
> prefix... pd might be desirable but if you can't then
the alternative is
> easy.

I thought we were all trying to discourage NAT in IPv6. 
Clearly, NAT
solves the problem ... while introducing 1000 new ones. 
:-/

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me
one chance [and] then I
won't contact you again." - Direct Marketing Ass'n
position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way
too many apples.

Joe Greco wrote:
>> It's likely that the device may choose to nat when
they cannot obtain a
>> prefix... pd might be desirable but if you can't
then the alternative is
>> easy.
> 
> I thought we were all trying to discourage NAT in IPv6.


You/we are... Which is why you really need PD, and cpe needs
to be able
to hand out /64s on request to downstream devices. Not
surprisingly that
will drive subnetting in the home. presently, plugging in
more
gateway/router devices results in multiple layers of nat and
huge
amounts of unnecessary complexity in the home network.

> Clearly, NAT
> solves the problem ... while introducing 1000 new ones.
 :-/

Sure, we don't have a reasonable mechanism for ipv4 devices
to pull
address space out of thin air. We do have one in ipv6. This
is a problem
that equipment makers (as much as randy hates them) will
have to
address. It doesn't take much imagination to figure out how
they will
address it given a lack of alternatives.

> ... JG

Joel Jaeggli wrote:
> equipment makers (as much as randy hates them)

excuse?!?!?  that is unjustified and uncalled for.

vendors, like everyone else, will do what is in their best
interests.
as i am an operator, not a vendor, that is often not what is
in my best
interest, marketing literature aside.  i believe it benefits
the ops
community to be honest when the two do not seem to
coincide.

randy

Randy Bush wrote:
> Joel Jaeggli wrote:
>> equipment makers (as much as randy hates them)
> 
> excuse?!?!?  that is unjustified and uncalled for.
>
> vendors, like everyone else, will do what is in their
best interests.
> as i am an operator, not a vendor, that is often not
what is in my best
> interest, marketing literature aside.  i believe it
benefits the ops
> community to be honest when the two do not seem to
coincide.

If the ops community doesn't provide enough addresses and a
way to use
them then the vendors will do the same thing they did in v4.
It's not
clear to me where their needs don't coincide in this case.

there are three legs to the tripod

	network operator

	user

	equipment manufacturer

They have (or should have) a mutual interest in:

	Transparent and automatic configuration of devices.

	The assignment of globally routable addresses to internet
	connected devices

	the user having some control over what crosses the boundry
	between their network and the operators.


> randy
> 

Tony Li wrote:
> Randy's attitude that vendor's are all unequivocally
evil

please read what i said, and not what joel, very
incorrectly, said what
i said.  then apologize.

randy

>> vendors, like everyone else, will do what is in
their best interests.
>> as i am an operator, not a vendor, that is often
not what is in my best
>> interest, marketing literature aside.  i believe it
benefits the ops
>> community to be honest when the two do not seem to
coincide.
> If the ops community doesn't provide enough addresses
and a way to use
> them then the vendors will do the same thing they did
in v4.

i presume you mean nat v6/v6.  this would be a real mess and
i don't
think anyone is contending it is desirable.  but this
discussion is
ostensibly operators trying to understand what is actually
appropriate
and useful for a class of customers, i believe those of the
consumer,
soho, and similar scale.

to summarize the positions i think i have heard
  o one /64 subnet per device, but the proponent gave no
estimate of the
    number of devices
  o /48
  o /56
  o /64
the latter three all assuming that the allocation would be
different if
the site had actual need and justification.

personally, i do not see an end site needing more than 256
subnets *by
default*, though i can certainly believe a small minority of
them need
more and would use the escape clause.  so, if we, for the
moment, stick
to the one /64 per subnet religion, than a /56 seems
sufficient for the
default allocation.

personally, i have a hard time thinking that any but a
teensie minority,
who can use the escape clause, need more than 256.  hence, i
just don't
buy the /48 position.

personally, i agree that one subnet is likely to be
insufficient in a
large proportion of cases.  so keeping to the /64 per subnet
religion, a
/64 per site is insufficient for the default.

still personally, i think the one /64 subnet per device is
analogous to
one receptacle per mains breaker, i.e. not sensible.

> there are three legs to the tripod
> 	network operator
> 	user
> 	equipment manufacturer
> They have (or should have) a mutual interest in:
> 	Transparent and automatic configuration of devices.

as you have seen from chris's excellent post [0] on this
one, one size
does not fit all.  this is likely another worthwhile, but
separate,
discussion.

> The assignment of globally routable addresses to
internet
> connected devices

i suspect that there are folk out there who equate nat with
security.  i
suspect we both think them misguided.

> The user having some control over what crosses the
boundry
> between their network and the operators.

yup

randy

---

[0] - <http://www.merit.edu/mail.archives/nanog/msg04887.html
>

Randy Bush wrote:
>>> vendors, like everyone else, will do what is in
their best interests.
>>> as i am an operator, not a vendor, that is
often not what is in my best
>>> interest, marketing literature aside.  i
believe it benefits the ops
>>> community to be honest when the two do not seem
to coincide.
>> If the ops community doesn't provide enough
addresses and a way to use
>> them then the vendors will do the same thing they
did in v4.
> 
> i presume you mean nat v6/v6.  this would be a real
mess and i don't
> think anyone is contending it is desirable.  but this
discussion is
> ostensibly operators trying to understand what is
actually appropriate
> and useful for a class of customers, i believe those of
the consumer,
> soho, and similar scale.
> 
> to summarize the positions i think i have heard
>   o one /64 subnet per device, but the proponent gave
no estimate of the
>     number of devices
>   o /48
>   o /56
>   o /64

It plausible that if one were to assign a single /64 and
reserve a 56 to
delegate per customer that you could number about 16 million
customers
per /32 with a few hundred thousand /64s remaining for
infrastrucuture.
size of an agregate for a pop might be /48 (~250 customers)
to /40 (65k
customers) to /36 (1 million customers)

A large retail isp might under those circumstances be able
to get away
with order of /28 to /30 in total.

> the latter three all assuming that the allocation would
be different if
> the site had actual need and justification.
> 
> personally, i do not see an end site needing more than
256 subnets *by
> default*, though i can certainly believe a small
minority of them need
> more and would use the escape clause.  so, if we, for
the moment, stick
> to the one /64 per subnet religion, than a /56 seems
sufficient for the
> default allocation.
> 
> personally, i have a hard time thinking that any but a
teensie minority,
> who can use the escape clause, need more than 256. 
hence, i just don't
> buy the /48 position.

> It plausible that if one were to assign a single /64
and reserve a 56 to
> delegate per customer

as a provider, where is the win in this for me?  the space
is 'lost',
i.e. committed, and i increase provisioning hassles, though
maybe mildly
if i am skillful.  if/when the rirs sober up about ipv6
justification, i
will have a hard time showing an hd ratio without a lot of
zeros to the
immediate right of the decimal point.

or would you suggest that i recover the committed space if
unused?
under what conditions?  after how long?  and, when i
recover, do i
allocate the second (or 42nd) /64 to a new customer, leaving
them a
smaller cushion than the first user of that /56 received?

no easy answers.  but yes, giving them a /56 off the bat
feels a bit
reminiscent of giving them a /24 in ipv4.

randy