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

Hi Jen, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jen Linkova [mailto:furry13@gmail.com]
> Envoyé : mercredi 4 décembre 2019 22:52
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Bjørn Mork; dhcwg@ietf.org; V6 Ops List; draft-link-dhc-
> v6only@ietf.org
> Objet : Re: [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.

[Med] I think this design is suboptimal. 

Instead of requiring a PREFIX64 RA option (changes to hosts/routers) + DHCP option (changes to hosts/dhcp server) to solve your problem, you can achieve the same goal with one single DHCP option (PREF64) and without touching to the routers. 

> 
> 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.

[Med] The machinery will be almost the same as you are doing with your new option. You don't need to delay DHCPv4. The only difference is the signal on which to rely to make the decision.

NEW:
   The client MUST NOT configure the IPv4 address provided 
   in the DHCPOFFER if the client discovers a valid PREF64.

> 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