Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

On Thu, Dec 5, 2019 at 12:56 AM <mohamed.boucadair@orange.com> wrote:
> Blindly releasing the IPv4 address when an IPv6 connectivity is available is problematic because the host does not know if a NAT64 function is available for a given network attachment. A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address. No additional signal is needed in such case.

it would be no difference from what
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag was
proposing. And as many of us know, that draft was not able to reach
consensus, the main objection being 'we can not allow an IPv6 packet
to turn off IPv4'.
What dhc-v6only draft does is  allowing the DHCPv4 server to be
configured in such way that  hosts can selectively turn off IPv4. No
IPv6 traffic involved, everything operates over IPv4.

> Jen, do you have a case where you want to deploy IPv6-only host without announcing pref64 to that host?

I *am* deploying them right now, because pref64 draft is with IESG
right now and many of my routers are not able to send out PREF64 RA
option yet.

I agree that in theory pref64 presence is a very good implicit signal
for 'you don't really need IPv4'. However when a host connects to a
network it does not know if pref64 is available when it starts DHCPv4
process. So to use RAs as a signal you need to either delay DHCPv4 (==
penalize v4-only and dual-stack networks) or do all those undesirable
RELEASE tricks later.
I believe this is discussed in the Introduction and the Section 2 of
the draft but I'll look into how to clarify the text.

> > -----Message d'origine-----
> > De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Bjørn Mork
> > Envoyé : mercredi 4 décembre 2019 14:31
> > À : Jen Linkova
> > Cc : dhcwg@ietf.org; V6 Ops List; draft-link-dhc-v6only@ietf.org
> > Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option
> >
> > Jen Linkova <furry13@gmail.com> writes:
> >
> > > Hello,
> > >
> > > One of the biggest issue in deploying IPv6-only LANs is how to do it
> > > incrementally, when some hosts work just fine in NAT64 environment
> > > while some legacy devices still need IPv4. Doubling the number of
> > > network segments (having an IPv6-only and dual-stack segments of each
> > > type) is an operational nightmare. So it would be just awesome if all
> > > devices can co-exist in the same network segment and hosts capable of
> > > operating in IPv6-only environment do not consume IPv4 addresses.
> > > So here is the draft proposing a new DHCPv4 option to help saving IPv4
> > > addresses and deploying IPv4-as-a-service:
> > >
> > > Name:           draft-link-dhc-v6only
> > > Revision:       00
> > > Title:          IPv6-Only-Preferred Option for DHCP
> > > Document date:  2019-12-04
> > > Group:          Individual Submission
> > > Pages:          9
> > > URL:
> > > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt
> > > Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
> > > Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-00
> > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-
> > v6only
> > >
> >
> >   "While IPv6-only capable devices might use a
> >    heuristic approach to learning if the network provdes IPv6-only
> >    functionality and stop using IPv4 if it does, it might be practically
> >    undesirable.  One important reason is that when a host connects to a
> >    network, it does not know if the network is IPv4-only, dual-stack or
> >    IPv6-only.  To ensure that the connectivity over whatever protocol is
> >    present becomes available as soon as possible the host usually starts
> >    configuring both IPv4 and IPv6 immidiately.  If hosts were to delay
> >    requesting IPv4 until IPv6 reachability is confirmed, that would
> >    would penalize IPv4-only and dual-stack networks, which does not seem
> >    practical. "
> >
> >
> > Why can't the client just release the IPv4 address when it finds it has
> > IPv6 connectivity?  This would also avoid the problems you introduce
> > when the network falsely claims IPv6 support.
> >
> >
> >
> > Bjørn
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg

-- 
SY, Jen Linkova aka Furry