See below...
On 29/06/2015 09:09, Pierre Pfister wrote:
>
>
>> Le 28 juin 2015 à 22:00, Brian E Carpenter <[email protected]> a
>> écrit :
>>
>> On 29/06/2015 01:09, Pierre Pfister wrote:
>>> Hello,
>>>
>>>> Le 28 juin 2015 à 10:58, Gert Doering <[email protected]> a écrit :
>>>>
>>>> Hi,
>>>>
>>>> On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
>>>>> Relaxing the « administrator » may be confusing, as Brian said.
>>>>> So I guess the MUST could become a SHOULD, which imply it requires
>>>>> implementers to fully understand the drawbacks
>>>>> of using non-64 prefix lengths. For instance, /127 could be automatically
>>>>> used (no need for administrator) if a link
>>>>> is auto-detected as point-to-point.
>>>>
>>>> A MUST is perfectly right here. You can't have implementation A decide
>>>> "let's use a /64 here" while implementation B goes for "/127"…
>>>
>>> You actually can have implementations with different prefix length.
>>> This is handled by the prefix assignment algorithm.
>>
>> Yes, you need that ability in the protocol, but it won't work in practice
>> to pick an oddball like /80 unless all the host stacks on the link can
>> handle a shorter IID like 48 (whether it's a LAN or a pt2pt). RFC 7421.
>
> Which is why /64 SHOULD be preferred.
> We also have this:
> "In any case, a router MUST support a mechanism suitable to distribute
> addresses from the considered prefix to clients on the link.
> Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
> IPv4 prefix MUST support the L-capability and a router assigning an
> IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST
> support the H-capability as defined in Section 10
> <https://tools.ietf.org/html/draft-ietf-homenet-hncp-06#section-10>.
> "
>
> So a router will not advertise a /80 on a typical link unless it implements
> stageful DHCPv6.
>
>>
>>> You may have multiple routers with multiple prefix lengths, but one single
>>> prefix is ultimately chosen and used by all routers connected to the link.
>>
>> So will it work if one router on a pt2pt expects to use a /127 and the other
>> one can only support /64?
>
> The current document does not specify how to configure a pt2pt link.
> This could be specified later really easily, in a backward compatible way.
> Also, in general, why and how would a router assign a /64 to a pt2pt link ?
I believe that RFC 7421 was needed because, in ISP land, people were
often assigning a /64 because they thought they had to, since all
the IID mechanisms assumed /64. So there was no reason for it, it was
just human behaviour.
> I mean, considering pt2pt link, we can assume both ends of the link know the
> nature of the link…
> and are therefore able to not do weird things such as assigning a /64 on a
> pt2pt link.
I hope you are right. "Don't be weird" is a good motto, but "SHOULD conform
to RFC 7421" might be better in an RFC ;-).
(But then: do you want the SOHO network to automatically reserve a /64
out of which you take all the /127s for pt2pt links?)
Brian
Brian
>
> - Pierre
>
>>
>> Brian
>>
>>>
>>> - Pierre
>>>
>>>>
>>>> The sentence is also clearly allowing alternatives: if I tell my router
>>>> "hey, I want to use /127s on point-to-point links", this is "unless
>>>> configured
>>>> otherwise by an administrator", so the MUST is not getting in the way then.
>>>>
>>>> Gert Doering
>>>> -- NetMaster
>>>> --
>>>> have you enabled IPv6 on something today...?
>>>>
>>>> SpaceNet AG Vorstand: Sebastian v. Bomhard
>>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
>>>> D-80807 Muenchen HRB: 136055 (AG Muenchen)
>>>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
>>>>
>>>> _______________________________________________
>>>> 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
>
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
