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.
   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]> a écrit :

> 
> 
>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter <[email protected]> 
>> wrote:
>> 
>>> On 09/10/2014 03:21, Tim Chown wrote:
>>>> On 8 Oct 2014, at 14:14, Pierre Pfister <[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]
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to