Hello Pierre,
Le 09/10/2014 11:26, Pierre Pfister a écrit :
[...]
The following table MAY be used as default values, where X is the
length of the delegated prefix.
If X <= 64: Prefix length = 64
I disagree. In general, for assigning prefixes, and subsequently
routing to them, I do not understand why should one recommend any prefix
length at all, and even less to make it default.
This default prefix len above may prohibit one in a homenet to be an ISP
for other smaller IoT networks.
Look, we have another draft in 6man that calls for adoption,
draft-boucadair-6man-prefix-routing-reco-00. That draft recommends the
following:
Forwarding and routing protocols MUST NOT restrict by design the
length of IPv6 prefixes. In particular, forwarding and routing
processes MUST be designed to accept prefixes of any length up to
/128.
What do you think?
Alex
….
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
