[dhcwg] Re: [v6ops] Fwd: New Version Notification for draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts-00.txt

--===============8564019247663544457==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


This is about draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts-00.txt

I've added dhcwg, in part because of: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-=
06
and RFC7341.  I think DHC should consider adopting this.

Nice blog entry: https://ipv6tao.blogspot.com/2025/12/nearly-ipv6-only-dual=
-stack-hosts.html
Many comments below.

Mark Smith <[email protected]> wrote:
    >> > Comments and feedback most welcome and appreciated.
    >>
    >> I guess you have tried this with a bunch of existing clients?

    > I've tried it with Windows 11, and a number of Linux distros or based
    > OSes which use different DHCPv4 clients, e.g. Fedora 43, Rasberry PI =
OS
    > based on Debian Trixie, Chromecasts, and Google Nest.

Great!  Again, -I'm not convinced this is worth an RFC-, but it is a useful
thing to know.  I'd be interested to know if this technique is a win over
just giving out 1918 addresses with no default route.
Many hosts *do* v4-connectivity checks, and this will certainly fail.
(I notice you didn't manage to test this against any smartphones. I also am
concerned about some devices deciding they have to continue using their LTE
because the wifi isn't "good enough")

I suspect that many enterprise routers might be able to offer DHCPv4 without
having v4 addresses on the link.  Does that save on some resources?  NC ent=
ries?
{because sending DHCPv4 replies requires going below the normal ARP process,
I would think it would not necessarily require v4.  I haven't poked at KEA's
low-level code.  Old ISC DHCP relay can probably cope}

    >> I've stopped subnetting my (public) v4, and I distribute public v4 to
    >> machines that need it manually via /32 routes to their 1918 addresse=
s.
    >> The /32 addresses go on lo, with /32 [255.255.255.255] masks.  It
    >> would be neat if I could route over v6 the way that
    >> https://datatracker.ietf.org/doc/draft-ietf-intarea-v4-via-v6/05/
    >> does.
    >>

    > Reminds me of this, which is where the original idea of using
    > 255.255.255.255 subnet masks came from.

    > "A dirty trick to save a couple of IPv4 addresses on a LAN link"
    > "https://www.ausnog.net/sites/default/files/ausnog-2018/presentations=
/2.10.2_Mark_Smith_AusNOG2018_Lightning.pdf

I wonder if I read a version of this.
For me, it's not *just* the saving of .0 and .255 that is a win, it's that
with AS26227's single /24 and historically three buildings (now one since
September), we subnetted a lot, and then we'd have the wrong size subnets
over time.

    > https://datatracker.ietf.org/doc/html/draft-smith-v6ops-nearly-ipv6-o=
nly-dualstack-hosts-02

    > and here is the diff between -00 and -02

    > https://author-tools.ietf.org/iddiff?url1=3Ddraft-smith-v6ops-nearly-=
ipv6-only-dualstack-hosts-00&url2=3Ddraft-smith-v6ops-nearly-ipv6-only-dual=
stack-hosts-02&difftype=3D--html

    > Thanks very much, Mark.

So again, I think Informational is wrong for this.
{Insert procon rant about how we have broken that category, and use it wron=
g}

Since I wrote my first sentence above I've changed my mind:
It's either BCP, or it's standards track! Yes!

The reason why STD is because:
1. someone might want to demand support for this in their dhclient or serve=
r.
   (And technically, an Informational RFC is not trade-agreement compliant =
as
   a performance specification.  Yes, nobody in procurement knows that}

2. someone might *break* this behaviour in the future, and being able to ci=
te
a std as being violated.

About:
   In keeping with the broader goal of minimising IPv4 deployment to
   just where it is necessary, an alternative and preferred method of
   relaying DHCPv4 to the DHCPv4 server would be over a point-to-point
   IPv4 in IPv6 tunnel [RFC2473], established directly between the
   DHCPv4 relay and the DHCPv4 server.

I think that we also have draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06 and RFC73=
41.

Now, about the "dirty trick" above.
Should it be in scope for this?
And if so, is there a v4-over-v6 mechanism and/or IPv4-nexthop-v6 mechanism
that we can deploy?  Obviously that probably *does* require host changes.
Can those of us that need to push a single (public) v4 into some host "deep=
" in a
v6-only network do this more dynamically?

As you write, one might need a unique v4 per host because of potential
RFC5227 use.  I didn't know of 5227.  I haven't seen it widely implemented,
but I don't have many apple devices.  given that Stuart authored 5227, I
imagine it's ubiquitous among apple devices.   One could, I think use the
same prefix across many subnets.   Maybe Class E space :-)
{yes.  How many will be cused to see 255.255.255.255/255.255.255.255! }
The other interesting thing if we could pick a "standard" prefix is that it
means it could be implemented in a self-contained DHCPv4 server in a router.

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        |    IoT architect =
  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails  =
  [


=2D-
Michael Richardson <[email protected]>   . o O ( IPv6 I=C3=B8T consulti=
ng )
           Sandelman Software Works Inc, Ottawa and Worldwide





--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmk9hwwACgkQgItw+93Q
3WUD5QgAjJYE+nFsZP8kdKEmf+r7iQDykjimudrRGSMzpZmcMNd+v1MeAPZfQdpz
gt9Sl4GvmSmHKUW3P6Ffpw0TJSPpedeR23vvxu5MQVAsmMvLOc1r1oa5DitH+Fzs
6wR2ZfjRy4VGeBTN4ThcDKK9GVyJKXoteADUR19u2eB+KY/JyQrcMYQiXMhfe+Qj
giq08ikIppAEdnCMNnkoapgCbvc0Jm9XTejRljbq/MdKLvH0KouZKUkvHRyFmvG6
jrm26yBK0EQSuOAdDNxdowMTClYYbw43R+Ltif+j7VH2Hu2WMPABJ922AHJSxFFN
TrfaH7SJzd3lGWg7WEVD8gH1shTxKA==
=gTr5
-----END PGP SIGNATURE-----
--=-=-=--


--===============8564019247663544457==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp
bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK

--===============8564019247663544457==--