Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

[Mark Smith <[e-mail]>]

On 12 July 2017 at 13:18, Manfredi, Albert E
<[e-mail]> wrote:
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
>
>> Very specifically, it would be irresponsible not to require
>> pseudo-random IIDs of at least N bits for automatically assigned
>> addresses. RFC7217 doesn't define N, but I assume it would be at
>> least 40 and probably more.
>
> Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance.
>

How many are enough, and do you expect non-technical end-users to make
good decisions about how many bits they need for their privacy and
security?

RFC5505, "Principles of Internet Host Configuration"

"2.1.  Minimize Configuration

   Anything that can be configured can be misconfigured."

>> The advantage of requiring or recommending 64 bits is that it
>> avoids the debate about N.
>
> But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?).
>So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64,

/64 per-site looks to be proving to be the exception rather than the
rule. I've been casually observing what ISPs give out, because having
worked at residential ISPs (and one who provided the first production
IPv6 on residential broadband in Australia back in 2011), they've
tended to make static IPv4 addresses and routed subnets a premium or
business only product option with a corresponding price premium. I
expected that becoming a standard IPv6 feature may be resisted
significantly.

Most are giving out /56s. I know of one that is now giving out /60s,
and they originally gave out a single /64. I know of one that is
giving out a single /64 on their residential plans, and in the forum
that is being complained about, people are pointing out that other
ISPs are giving out /56s.

Here in Australia it is usual for our incumbent Telco to charge the
most, sometimes for the least, yet they too are giving out /56s
standard on residential plans.

In a market where there is choice, being miserly with assigned IPv6
address space won't persist for long if it causes trouble for
customers - the time and staff cost of dealing with their complaint
will outweigh any costs of giving them plenty of address space in the
first place.

> I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID.


What are the specific drawbacks or advantages of thermometer and
thermostats not having 64 bit IIDs? I can't think of any. It doesn't
reduce the code in them, nor can I see how it somehow reduces the
number of packets they need to send, and I don't see how if they were
battery operated it would make a beneficial difference to their
battery life.

Being hidden in a 64 bit IID address space does make them a less
likely target for a DoS attack, assuming they've somehow been made
reachable by somebody who would benefit from them being DoS'd.

What are some applications that would benefit from more flexibility?
Are you talking about applications where the flexibility would be an
additional benefit to the application, or ones where the flexibility
would be required to work around not having a 64 bit IID available?


>*Or* were built that way, because someone read that 64-bit IIDs are "required."
>

64 bit IIDs have been written as required since July 1998 in RFC2373.
In some countries this requirement can drive, vote in elections and
drink alcohol.


"In a number of the format prefixes (see section 2.4) Interface IDs
   are required to be 64 bits long and to be constructed in IEEE EUI-64
   format [EUI64]."

...

"  The details of forming interface identifiers are defined in the
   appropriate "IPv6 over <link>" specification such as "IPv6 over
   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc."



Regards,
Mark.