Re: [v6ops] draft-troan-v6ops-extending-network-reqs

[Lorenzo Colitti <[e-mail]>]

The draft completely ignores IPv6's ability to provide global end-to-end
connectivity.

It does not cite it as a goal or, AFACIT, even mention it at all. This is a
major problem I think. As an example, this line of thinking leads to the
statement that the only mechanism that is guaranteed to work is NAPT66
because it's self-similar, and provides infinite extension. I wouldn't
agree that it "works". Yes, it provides infinite extension. But it only
provides infinite extension of partial connectivity. There's no advantage
to doing that. We might as well provide the extended devices only with IPv4
connectivity. At least IPv4 stacks and applications are used to having to
work around NAT, unlike IPv6 applications.

I don't think we should publish anything about mechanisms that don't
provide end-to-end connectivity, except maybe to discourage their use. They
are great from a network operator perspective, but very painful for
application developers.

The draft tries to separate the mechanisms to extend the network from the
mechanisms used to assign addresses. But I suspect that once we factor in
the need (or even just the desire) to factor in end-to-end connectivity,
those two can no longer be separated. For example: does DHCPv6 prefix
delegation provide end to end connectivity? There is no way to answer that
without knowing how addresses are assigned downstream. Delegating a /126 to
a device that wants to share connectivity with two other devices does.
Delegating it to a device that wants to share connectivity with 8 devices
doesn't.

On Sat, Oct 7, 2023 at 3:02 AM Ole Troan <otroan=
[e-mail]> wrote:

> With draft-ietf-v6ops-dhcp-pd-per-device focusing on network behaviour I
> just submitted this (very) early draft on how the node extending the
> network should behave.
> It is intended as a companion draft to pd-per-device, but also trying to
> cover the use cases where pd-per-device is not enabled on the upstream
> link, or does not provide enough address space for assigning a /64 on every
> downstream link.
>
> Co-authors much desired.
>
> Best regards,
> Ole
>
>
> A new version of Internet-Draft
> draft-troan-v6ops-extending-network-reqs-00.txt has been successfully
> submitted by Ole Troan and posted to the
> IETF repository.
>
> Name:     draft-troan-v6ops-extending-network-reqs
> Revision: 00
> Title:    Extending the Network - Host Requirements
> Date:     2023-10-05
> Group:    Individual Submission
> Pages:    8
> URL:
> https://www.ietf.org/archive/id/draft-troan-v6ops-extending-network-reqs-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-troan-v6ops-extending-network-reqs/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-troan-v6ops-extending-network-reqs
>
>
> Abstract:
>
>    This memo describes the behaviour of a node that when connecting to a
>    network, offers connectivity via itself to other nodes (or entities
>    needing addresses) connected to it.  The focus is on IPv6
>    connectivity, but the same principles could be applied to IPv4.
>
>
>
> The IETF Secretariat
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>