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

["Bernie Volz (volz)" <[e-mail]>]

There is also a question of whether the V6ONLY-WAIT time value that the client should use be returned in the option - i.e., the option should be a 4 (or 2) octet option returning an unsigned integer of the time. Perhaps returning 0 indicates the client should use its default (thus the valid values would be 0 or 300 >= value <= max (86,400 sec, 24 hours?)).

This was discussed while draft was in development but we didn't end up with a decision. So, worth discussing a bit on list.


A minor note about the draft requesting use of (DHCPv4) option code 108. Per RFC3679 this was in use as a "swap path" option at some point, though never published as a draft. That is why it is marked as "REMOVED/unassigned" as the idea was to NOT reuse these option numbers until there was a need (i.e., no other just "unassigned" option codes were available). While I have no objection if the draft wishes to request use of that option code, I just wanted to point out that there could be some other conflicting usage out in the wild.

- Bernie

-----Original Message-----
From: v6ops <[e-mail]> On Behalf Of Ted Lemon
Sent: Wednesday, December 4, 2019 12:29 PM
To: Jen Linkova <[e-mail]>
Cc: [e-mail]; V6 Ops List <[e-mail]>; [e-mail]
Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

This is good in principle. The client behavior section should require the client to send a parameter request list and to specify the option code of the new option in the list along with any other options it expects to get. 

> On Dec 4, 2019, at 04:09, Jen Linkova <[e-mail]> wrote:
> 
> 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
> 
> 
> Abstract:
>   This document specifies a DHCP option to indicate that a host
>   supports an IPv6-only mode and willing to forgo obtaining a IPv4
>   address if the network provides IPv6 access.
> 
> Any comments/suggestions/reviews are highly appreciated!
> 
> Adding v6ops@ to Cc: as the problem is related to operating IPv6-only networks.
> 
> Thank you!
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops