[dhcwg] Re: Generation/Selection of IPv6 addresses by DHCPv6 servers (Fwd: New Version Notification for draft-gont-dhcwg- dhcpv6-iids-00.txt)

L2 switching network in ipv4 shared by ISP  prefixeS x multi @hosters ,
downstream  clients in LAN , intrAnet , even ce R not control wan
connections ,

End user communication in dhcpv6 is not warrantying the REAL TIME, or and
ture speaker...



Sincerely
On Fri, Mar 21, 2025, 01:37 Templin (US), Fred L <Fred.L.Templin=
[email protected]> wrote:

> Fernando,
>
> I read your draft and like what it is proposing to the point I would like
> to see it get adopted
> by the working group. My one comment is regarding the possibility for
> address duplication
> and the responsibility for duplicate detection/avoidance. On links where
> there may be
> multiple DHCPv6 servers that serve addresses from the same IPv6 prefix but
> might not
> actively synchronize their lease databases, the client should perform DAD
> and decline
> any address delegations detected as duplicates. But, on links where there
> is operational
> assurance that no two servers can ever return duplicate addresses (e.g.,
> when no two
> servers serve addresses from the same IPv6 prefix) clients should be able
> to rely on the
> address uniqueness properties of the DHCPv6 service and set
> DupAddrDetectTransmits
> for the link to 0 [RFC4862].
>
> To the working group - please adopt this as a working group item pending
> resolution
> of the above comment.
>
> Thank you - Fred Templin
>
> > -----Original Message-----
> > From: Fernando Gont <[email protected]>
> > Sent: Monday, February 10, 2025 12:51 PM
> > To: [email protected]
> > Subject: [dhcwg] Generation/Selection of IPv6 addresses by DHCPv6
> servers (Fwd: New Version Notification for draft-gont-
> > dhcwg-dhcpv6-iids-00.txt)
> >
> > Hi, all,
> >
> > I recently happened to run into draft-ietf-dhc-rfc8415bis-07, and was
> > glad to find that it does provide some advice regarding the generation
> > of IPv6 addresses by DHCP6 servers. (Coincidentally or not, this is
> > aligns with the recent work in RFC9416 regarding transient numeric
> > identifiers).
> >
> > In that regard, I've posted this I-D (draft-gont-dhcwg-dhcpv6-iids):
> >
> >   * URL:
> https://www.ietf.org/archive/id/draft-gont-dhcwg-dhcpv6-iids-00.txt
> >   * HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-gont-dhcwg-dhcpv6-iids
> >
> > with the goal of producing a Standards Track specification of the
> > algorithm in RFC7943, such that it can be better referenced (or
> > recommended, as noted in RFC9416) in future revisions of the DHCPv6 spec
> > (no, I'm not meaning the current  draft-ietf-dhc-rfc8415bis effort, but
> > future ones).
> >
> > Feedback will be welcome!
> >
> > Thanks,
> > Fernando
> >
> >
> >
> >
> > -------- Forwarded Message --------
> > Subject: New Version Notification for draft-gont-dhcwg-dhcpv6-iids-00.txt
> > Date: Mon, 10 Feb 2025 12:40:54 -0800
> > From: [email protected]
> > To: Fernando Gont <[email protected]>
> >
> > A new version of Internet-Draft draft-gont-dhcwg-dhcpv6-iids-00.txt has
> been
> > successfully submitted by Fernando Gont and posted to the
> > IETF repository.
> >
> > Name:     draft-gont-dhcwg-dhcpv6-iids
> > Revision: 00
> > Title:    A Method for Generating Semantically Opaque IPv6 Interface
> > Identifiers (IIDs) with Dynamic Host Configuration Protocol for IPv6
> > (DHCPv6)
> > Date:     2025-02-10
> > Group:    Individual Submission
> > Pages:    11
> > URL:
> > https://www.ietf.org/archive/id/draft-gont-dhcwg-dhcpv6-iids-00.txt
> > Status:   https://datatracker.ietf.org/doc/draft-gont-dhcwg-dhcpv6-iids/
> > HTMLized:
> https://datatracker.ietf.org/doc/html/draft-gont-dhcwg-dhcpv6-iids
> >
> >
> > Abstract:
> >
> >     This document describes a method for selecting IPv6 Interface
> >     Identifiers that can be employed by Dynamic Host Configuration
> >     Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
> >     addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
> >     algorithm that does not require any updates to the existing DHCPv6
> >     specifications.  The aforementioned method results in stable
> >     addresses within each subnet, even in the presence of multiple DHCPv6
> >     servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
> >     the method specified in RFC 7217 for IPv6 Stateless Address
> >     Autoconfiguration (SLAAC).
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > dhcwg mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> _______________________________________________
> dhcwg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]