Re: [v6ops] Updating RFC 7084

Yeah, obviously for this to work, we’d have to specify how, because at
present no such specification exists.

Op zo 20 nov. 2022 om 19:59 schreef Lorenzo Colitti <lorenzo@google.com>

> As for multihoming, how would a DHCPv6 PD client get one PD per PVD? I'd
> guess that most PD clients only support one server response. In general I'm
> very confused about how DHCPv6 deals with multiple servers. RFC 8415
> section 18.2.10 seems to support it, but it also seems to assume that all
> servers are run by the same entity, because it says things like "Advertise
> messages with the highest server preference value SHOULD be preferred over
> all other Advertise messages", which sort of only makes sense if the
> preference values are comparable (i.e., set by the same operator).
>
> On Fri, Nov 18, 2022 at 11:57 PM Ted Lemon <mellon@fugue.com> wrote:
>
>> I'll paraphrase my comment on SNAC about this, because we had a good
>> discussion there and I think this is actually more of a v6ops thing than a
>> SNAC thing (there's debate on the SNAC mailing list about whether we'd want
>> to do multi-homing even if the infrastructure supports it).
>>
>> DHCPv6 PD assumes that the network is managed by a single entity, and so
>> if the network is multihomed, you can communicate with a single DHCPv6
>> server and get all the information you need. There are a lot of reasons why
>> this is no longer correct. The first is that DHCPv6 doesn't (and can't)
>> support Provisioning Domains (PvDs). The second is that a very likely
>> scenario for a multi-homed home network (if any such scenario is at all
>> likely!) is that you have two CE routers connected to the same link, each
>> of which is advertising an RA on the link. Hosts on the link see both RAs
>> and are therefore multihomed.
>>
>> RFC7084 doesn't talk about the PvD RA option for the simple reason that
>> the document that describes it was written long after 7084. Now that we
>> have such an option, it seems like an excellent way to indicate that the
>> network is multi-homed: each CE router can advertise a different PvD. How
>> they are defined is something we'd have to figure out, but in principle
>> this seems like a reasonable approach.
>>
>> Why do we care? Because probably a DHCPv6 PD /client/ should be trying to
>> get one PD per PvD, not one PD total. A DHCPv6 PD client that doesn't do
>> this is only ever going to get a PD from one of the two CE routers, and
>> which one it gets isn't going to be deterministic. So this is a really
>> clear limitation for multi-homed networks in this scenario. RFC7084-bis
>> could clarify how this works, and I think it should. It's possible that
>> we'd also need a document in the DHC working group talking specifically
>> about the DHCPv6 PD behavior in the presence of multiple PvD RAs.
>>
>> On Fri, Nov 18, 2022 at 9:47 AM Timothy Winters <tim@qacafe.com> wrote:
>>
>>> Hello,
>>>
>>> I've started a draft to update RFC 7084 to support prefix delegation on
>>> the LAN interfaces.  The current state of IPv6 in home networks is ISP are
>>> assigning prefixes of appropriate sizes but they currently are under
>>> utilized due to the lack of prefix delegation on LAN interfaces.
>>>
>>> This draft is an attempt to add that support to the draft.
>>>
>>> https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
>>>
>>> This is only an update to 7084 at the moment, there has been some
>>> discussion on the snac working group about leveraging this work as well.
>>>
>>> One item being discussed is this currently doesn't solve multi-homed
>>> networks.
>>>
>>> I welcome any feedback about the proposal.
>>>
>>> ~Tim
>>> _______________________________________________
>>> 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
>>
>