Re: Why /64

[Alexandru Petrescu <[e-mail]>]

Le 27/10/2013 11:52, Ray Hunter a écrit :
> Lorenzo Colitti wrote:
>> On Sat, Oct 26, 2013 at 5:42 PM, Fred Baker (fred) <[e-mail]>
>> wrote:
>>
>>>> Is this the sole reason for requiring subnets to be a /64?
>>> It was the driver for the change from RFC 1884's /80 (with a 48
>>> bit MAC in the IID) to RFC 2373's /64 (with an EUI-64). I would
>>> think that any argument today about the /64 would be about
>>> inertia if not the EUI-64.
>>>
>>
>> I think the split /64 extremely useful because it provides a
>> minimum size assignment that makes autoconfiguration easy, allows
>> privacy, and gives users the capability to number multiple
>> applications or multiple devices without having to use NAT.
>>
>> I have personally had more than one conversation with operators who
>> cannot see why they would ever want to give a user more than one
>> IPv6 address, because a) that's what they do in IPv4, and b) a /64
>> is a waste of space. Mobile operators seem particularly prone to
>> this line of reasoning. Telling them that there's plenty of space
>> to give every device a /64, or that their service is better if
>> users are allowed more than a /64 for privacy reasons, or that it
>> allows users to connect multiple devices, etc. has no effect.
>> Saying "it's specified in the standards and some implementations
>> might not work if you don't do it" has proven to be a much better
>> argument so far. Often those same operators then come to appreciate
>> the flexibility once they have deployed using /64 or larger and see
>> how it makes things better and easier.
>>
>> It's true that some operators can decide to use only DHCPv6 and
>> hand out /128s today, but since some platforms don't support
>> DHCPv6, that decision has compatibility consequences.
>>
>> If we ditch the one-size-fits all subnet size and leave the subnet
>> size up to the operator, it's virtually certain that we will end up
>> with some deployments that hand out /128s. That makes IPv4-style
>> NAT virtually inevitable, because users will want to connect more
>> than one device regardless of what the operator wants them to do.
>> Since apps have to adapt to the lowest-common denominator
>> connection, there's a good chance that apps will have to keep
>> IPv4-style NAT traversal mechanisms around forever. I think that's
>> a fundamentally bad deal, because there's no real reason to employ
>> address sharing if you have enough addresses; the side-effects of
>> NAT that people seem to like (e.g., security) come from stateful
>> inpection, not from the translation itself.
>>
>> On the other hand, if we do keep a one-size-fits-all subnet size,
>> then I think /64 is the best choice, not just for backwards
>> compatibility reasons, but for lots of other reasons such as
>> because it splits the address in two halves that are natural
>> machine integer sizes, provides enough space to protect against the
>> birthday paradox, and so on.
>>
>> Cheers, Lorenzo
>>
> If I read the above, you seem to be arguing that dropping fixed /64
> would be a bad thing because operators will use this as an
> opportunity to limit their customers to a single IPv6 address, and
> yet simultaneously you seem to be arguing that maintaing a fixed /64
> is a good thing even though it limits customers to a single subnet.
>
> Do I understand you correctly? The logic doesn't seem very
> self-consistent to me.
>
> Me? I believe in CIDR.

The IPv4's CIDR concept (route based on bitwise borders, instead of
8byte) seems to me a good clue for the discussion about the fix 64bit
limit in IPv6.

Alex

>