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

Yes please, ideally with a comment to the effect that “Any of the mechanisms which do not provide complete end-to-end address transparency and connectivity should be considered sub-standard and implemented only in circumstances where no better alternative exists.”

Owen


> On Oct 10, 2023, at 13:45, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Ole,
> 
> To avoid a polemic here, maybe the draft should draw a clear line between solutions that do preserve e2e addresses and those that don't, with a note that the latter bring with them some or all of the documented issues with NAT. The topic is nicely described at https://www.rfc-editor.org/rfc/rfc6296.html#section-5 and of course in RFC 2993.
> 
> Regards
>   Brian Carpenter
> 
> On 10-Oct-23 19:00, Ole Troan wrote:
>>> The draft completely ignores IPv6's ability to provide global end-to-end connectivity.
>> The document tries to describe how an extending node can achieve (some level) of connectivity “no matter what”. The intention is to provide an ordered list of mechanisms. Where of course NAPT66 is quite close to the bottom.
>>> 
>>> 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.
>> IPv6 applications also need to deal with NAT. That unfortunately happened with NAT64. And there are other use cases in IPv6 where some sort of identifier / locator split is required.
>> For some use cases NAPT66 is an acceptable tradeoff. It’s an operational choice.
>> It certainly gives good enough connectivity to set up a tunnel which a more transparent service can be provided over.
>>> 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.
>> I’d much rather we described it so we have some hope of deterministic behaviour from extending hosts.
>>> 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.
>>> 
>> Yes, we may not quite have found the right way of representing the various dimensions.
>> Which mechanism is used upstream is to independent of which mechanism is used to assign addresses, and also independent of how the networks is further extended.
>> That said, if we take a DHCPv6 PD network. There are some benefits of flat delegation. In that each level of extension asks for the individual links it needs numbered from a central DHCPv6 server, instead of a hierarchal delegation. When the flat model “stops”, some of these other mechanisms will have to come into play though.
>> Cheers,
>> Ole
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops