Thanks for updating.
Le 09/10/2014 11:26, Pierre Pfister a écrit :
Hello,
I’m proposing this change then.
1. In case the provided prefix is 64, the default consist in assigning
prefixes of length 64 first.
2. I’m adding a reference to 6man-why64.
When the algorithm decides to make a new assignment, it first needs
to specify the desired size of the assigned prefix. Although this
algorithm intends to remain generic, it was observed in
[I-D.ietf-6man-why64] that hosts may malfunction when the prefix
length is not 64. Therefore, prefixes of length 64 are RECOMMENDED.
With this text above, operators will be encouraged to read and give /64
to end user sites.
Alex
The following table MAY be used as default values, where X is the
length of the delegated prefix.
If X <= 64: Prefix length = 64
….
Processes proposed in the appendix are optional.
Our implementation supports some part of it, and it works fine in our
test-cases.
I’d rather have a /80 than no connectivity at all (And it just works.).
IMO, why64 is way too pessimistic on the current implementation state
and even more when it comes to the progress implementations will do in
the coming years.
And we either do that or let people do NAT66. ;)
Is it OK for you Ole ?
Cheers,
- Pierre
Le 9 oct. 2014 à 07:25, Mark Townsley <[email protected]
<mailto:[email protected]>> a écrit :
On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
<[email protected] <mailto:[email protected]>> wrote:
On 09/10/2014 03:21, Tim Chown wrote:
On 8 Oct 2014, at 14:14, Pierre Pfister <[email protected]
<mailto:[email protected]>> wrote:
Why should we mandate homenet implementations to *brake* in
situations where they could work fine ? Why should we voluntarily
prevent a link from being configured if we actually can configure it ?
If MUSTs are the solution, then I would rather see a ‘ISP MUST
provide a /56 to customers’ than ‘Homenet MUST brake when the
provided prefix is not big enough’.
But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1
i.e. don’t go longer than /64, and ISPs should provide enough prefixes.
The why64 text is very relevant here.
And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).
Informative reference, as we don't want to create a downref over this.
Certainly the mechanisms should support any prefix length,
I agree.
- Mark
but
the reality remains that only /64 subnets work properly in all
circumstances today.
Brian
_______________________________________________
homenet mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
