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 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.
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.
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
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.
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