Charles E. Perkins a écrit :
Hello Alex,
Since you CC:'d me, I feel that it should be O.K. for me to supply
a response.
Alexandru Petrescu wrote:
Nonsense. "utility.. is limited" is not the same as "must not be
used".
Would you agree to say "the utility of /128 prefixes is limited"?
The utility of /128 prefixes is that using them enables solutions
in all circumstances.
Is that limited?
Yes, limited by its trade-offs (memory and search time you agree
below).
draft-baccelli says:
o A subnet prefix configured on this interface should be of
length /128.
The link-local prefix of IPv6 LLs is fe80::/10, and not /128.
The key word in that sentence is SHOULD. It does not say MUST.
Well, LLs are a SHOULD on many interfaces. A SHOULD and and a
SHOULD NOT could give a "MAY": "a /128 prefix on this interface
MAY be /128". (and I invite implementers to do it and report back
problems thank you).
You seem to have already dismissed the experience of many
implementors on this list.
Yes, we have an issue here.
Many implementers on this list have often disregarded the fact that the
LL address was there. Because of that, let us continue this complete
disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just
don't say LL - because they have always been completely disregarded -
let us have this draft reflect that particular implementer situation.
Disregarded in implementation, disregarded in the draft.
But don't say wrong things about them.
Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT").
In fact it is not helpful at all to understand what is at issue.
I tend to agree too.
draft-baccelli says:
o Any [IPv4] subnet prefix configured on this interface should
be of length /32.
Yet the prefix of the IPv4 LL is 169.254/16, and not a /32.
Again, the sentence says SHOULD. Not MUST.
Again, a MAY would be a better fit.
MAY is completely worthless in this context. It adds almost no
information, and absolutely no practical information.
Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing
lack of consensus. It is a big problem when trying to implement.
[...]
I believe that "dicouraged" fits better the use of host-based
routes (the "/128" prefix recommendation) for a variety of reasons,
making them limited use too:
(1) it doesn't scale to large domain,
How large do you need?
Hmmm, it can't become as big as the Internet is now.
(2) can't connect to the Internet,
Wrong.
Can we talk about it without going solution space?
I think we should talk about it in an addressing model draft which does
not disturb the non adhoc aware nodes (i.e. Internet nodes).
(3) consumes more ressources than /64-or-shorter prefixes (cycles:
instead of average 64 bit comparisons you use a sure 128 bit
comparisons, memory: instead of one entry covering several
destinations you use an entry for each destination in each router).
Here, I agree. Perhaps you might evaluate the cost of the memory.
Compare it to the cost of imposing more DAD or NUD cycles over the
air.
Hmm... I do like the distributed manner of DAD+SLAAC, instead of
req-resp messages between someone trying to obtain an address and
someone delivering it one. This latter has its own problems.
It sounds as we have it completely reverse, and "MAY" may solve it.
I don't think so.
Now that you say it, I think too so, a bit.
I think better get rid of them (LLs) entirely rather than talk in an
unconsensual way of them.
Then we'll see the /128s recommendation separately.
Alex
Regards, Charlie P.
_______________________________________________
Autoconf mailing list
Autoconf at ietf.org
https://www.ietf.org/mailman/listinfo/autoconf
