Subject: IPv6-only Operations

From: David Farmer <[email-masked]>
Date: Thu, 25 Oct 2018 12:41:49 -0500

I think part of the problem with draft-ietf-6man-ipv6only-flag is we need
to discuss all the options before selecting the way forward for this issue.
I suggest draft-ietf-6man-ipv6only-flag be put on hold and we work on a
draft discussing the problems of and mitigations for IPv6-only operations,
similar to RFC6104 Rogue IPv6 Router Advertisement Problem Statement.

Layer 2 filtering is obviously one option, but I think we also need
draft-ietf-6man-ipv6only-flag if nothing else to signal hosts that layer 2
filtering is taking place on the link network and therefore attempting to
use IPv4 is probably pointless. However, both of these options are really
only viable after you know there is no need for IPv4 routing on a link
network.

So, how is a network operator to determine if IPv4 routing is needed on a
link network? Right now most dual-stack hosts will happily take and use an
IPv4 address if DHCPv4 gives them one, whether or not they actually need it
or not. So, the only way to know for sure that IPv4 routing is needed on a
link network or not is to turn it off and see if anyone SCREAMS! While I
believe we need Layer 2 filtering and draft-ietf-6man-ipv6only-flag, it
seems to me, we need something else too. We need something to determine if
IPv4 routing is actually needed on a link network in the first place.

I think the way to do this is to signal to dual-stack hosts using a DHCPv4
option that the IPv4 address provided is optional and should be used only
if the host cannot configure and utilize IPv4AAS for itself.  Then
eventually you will have all host on a link network only configuring IPv6
even though IPv4 is available to them on the link network if they needed
it.  Once this occurs, and enough time passes, it will probably be
reasonably safe to disable IPv4 on the link network by implementing layer 2
filtering and/or draft-ietf-6man-ipv6only-flag.

So I think the way forward is an IPv6-only Problem Statement Draft thinking
through the whole transition from dual-stack IPv4/IPv6 to IPv6-only
operations, get consensus on that first. With that If
draft-ietf-6man-ipv6only-flag still makes sense, which I think it will,
then move it forward along with any other conclusions from an IPv6-only
Problem Statement Draft. Note that draft-ietf-6man-ipv6only-flag has a good
start of an IPv6-only Problem Statement. Also, this could allow
draft-ietf-6man-ipv6only-flag to be simplified to just the flag
implementation parts and the full discussion of the problem space should be
in the IPv6-only Problem Statement Draft.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 25 Oct 2018 19:56:31 +0200 (CEST)

On Thu, 25 Oct 2018, David Farmer wrote:

> operations, get consensus on that first.

I think this is an excellent suggestion. However, I don't think 6man might 
be the best place to have this discussion. To get proper attention to the 
problem as an operational problem statement, one thought would be to ask 
if v6ops could work on this problem and add it to its charter?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Oct 2018 08:58:27 +1100

> On 26 Oct 2018, at 4:41 am, David Farmer <[email-masked]> wrote:
> 
> I think part of the problem with draft-ietf-6man-ipv6only-flag is we need to discuss all the options before selecting the way forward for this issue. I suggest draft-ietf-6man-ipv6only-flag be put on hold and we work on a draft discussing the problems of and mitigations for IPv6-only operations, similar to RFC6104 Rogue IPv6 Router Advertisement Problem Statement. 
> 
> Layer 2 filtering is obviously one option, but I think we also need draft-ietf-6man-ipv6only-flag if nothing else to signal hosts that layer 2 filtering is taking place on the link network and therefore attempting to use IPv4 is probably pointless. However, both of these options are really only viable after you know there is no need for IPv4 routing on a link network.
> 
> So, how is a network operator to determine if IPv4 routing is needed on a link network? Right now most dual-stack hosts will happily take and use an IPv4 address if DHCPv4 gives them one, whether or not they actually need it or not. So, the only way to know for sure that IPv4 routing is needed on a link network or not is to turn it off and see if anyone SCREAMS! While I believe we need Layer 2 filtering and draft-ietf-6man-ipv6only-flag, it seems to me, we need something else too. We need something to determine if IPv4 routing is actually needed on a link network in the first place.

That something is called the human brain.  Turning off IPv4 will ALWAYS be a judgement call.

Is IPv4AAS available?
Do the hosts support the IPv4AAS method?
Do I need to use IPv4AAS?
Is there anything that we need locally that is IPv4 only?

> I think the way to do this is to signal to dual-stack hosts using a DHCPv4 option that the IPv4 address provided is optional and should be used only if the host cannot configure and utilize IPv4AAS for itself.  

Why? I also don’t think we need it at all because we have address selection rules which are quite capable of achieving the same effect.

> Then eventually you will have all host on a link network only configuring IPv6 even though IPv4 is available to them on the link network if they needed it.  Once this occurs, and enough time passes, it will probably be reasonably safe to disable IPv4 on the link network by implementing layer 2 filtering and/or draft-ietf-6man-ipv6only-flag.

If you have IPv4AAS the ONLY thing you NEED IPv4 is for local communication to devices/services that
are IPv4 only.

> So I think the way forward is an IPv6-only Problem Statement Draft thinking through the whole transition from dual-stack IPv4/IPv6 to IPv6-only operations, get consensus on that first. With that If draft-ietf-6man-ipv6only-flag still makes sense, which I think it will, then move it forward along with any other conclusions from an IPv6-only Problem Statement Draft. Note that draft-ietf-6man-ipv6only-flag has a good start of an IPv6-only Problem Statement. Also, this could allow draft-ietf-6man-ipv6only-flag to be simplified to just the flag implementation parts and the full discussion of the problem space should be in the IPv6-only Problem Statement Draft.

Quite frankly people have been going IPv6-only for a while now.  They are making that choice without any guidance from the IETF.  When we did it experimentally, by not having DHCPv4 configured, we noticed there was legacy IPv4 traffic and that was about it.  What is there beyond “how do we tell nodes that IPv4 shouldn’t be used on this link”?

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Thu, 25 Oct 2018 18:12:01 -0500

On Thu, Oct 25, 2018 at 4:58 PM Mark Andrews <[email-masked]> wrote:

> > I think part of the problem with draft-ietf-6man-ipv6only-flag is we
> need to discuss all the options before selecting the way forward for this
> issue. I suggest draft-ietf-6man-ipv6only-flag be put on hold and we work
> on a draft discussing the problems of and mitigations for IPv6-only
> operations, similar to RFC6104 Rogue IPv6 Router Advertisement Problem
> Statement.
> >
> > So, how is a network operator to determine if IPv4 routing is needed on
> a link network? Right now most dual-stack hosts will happily take and use
> an IPv4 address if DHCPv4 gives them one, whether or not they actually need
> it or not. So, the only way to know for sure that IPv4 routing is needed on
> a link network or not is to turn it off and see if anyone SCREAMS! While I

So how do you know these things? Especially in a BYOD environment? I'm
looking to enable a data-driven decision.

> > I think the way to do this is to signal to dual-stack hosts using a
> DHCPv4 option that the IPv4 address provided is optional and should be used
> only if the host cannot configure and utilize IPv4AAS for itself.
>
> Why? I also don’t think we need it at all because we have address
> selection rules which are quite capable of achieving the same effect.
>

Doesn't happy-eyeballs mess with the address selection rules?  The address
selection rules don't cause the IPv4 address to remain unconfigured,
possibly IPv4 will be unused if happy-eyeballs isn't in use. Not having any
IPv4 leases is a much clearer signal that IPv4 is no longer needed on a
link network. Otherwise, you will have to take a close look that the IPv4
traffic potentially creating privacy issues in some situations.

> Then eventually you will have all host on a link network only configuring
> IPv6 even though IPv4 is available to them on the link network if they
> needed it.  Once this occurs, and enough time passes, it will probably be

In some situations local communication isn't allowed anyway and in others
I'm fine with IPv4 link-local until IPv4 can be turned off by implementing
layer 2 filtering and/or draft-ietf-6man-ipv6only-flag.

> > So I think the way forward is an IPv6-only Problem Statement Draft
> thinking through the whole transition from dual-stack IPv4/IPv6 to
> IPv6-only operations, get consensus on that first. With that If
> Quite frankly people have been going IPv6-only for a while now.  They are
> making that choice without any guidance from the IETF.  When we did it
> experimentally, by not having DHCPv4 configured, we noticed there was
> legacy IPv4 traffic and that was about it.  What is there beyond “how do we
> tell nodes that IPv4 shouldn’t be used on this link”?
>

In many environments what you say is true, especially where you have
control of the devices, we have done it in many experiments too. But in
public access BYOD environments, I think you need some way to measure the
issue. Large networks will probably never get to zero IPv4 usage, but if
you can measure you can decide when it is in the noise or it is a small
enough hit you are willing to take.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Oct 2018 11:23:51 +1100

> On 26 Oct 2018, at 10:12 am, David Farmer <[email-masked]> wrote:
> 
> 
> So how do you know these things? Especially in a BYOD environment? I'm looking to enable a data-driven decision.

Well if you don’t care about DNSSEC, DNS64 gets you 99.9% of the way there.  It is a IPv4AAS for sites reached by name.  For lots of nets it will just be disable IPv4 and see what breaks. You can alway reverse the decision and then address the issue that caused you to go back.

We don’t need to look for perfect.  We have good enough already.

> Doesn't happy-eyeballs mess with the address selection rules?  The address selection rules don't cause the IPv4 address to remain unconfigured, possibly IPv4 will be unused if happy-eyeballs isn't in use. Not having any IPv4 leases is a much clearer signal that IPv4 is no longer needed on a link network. Otherwise, you will have to take a close look that the IPv4 traffic potentially creating privacy issues in some situations.

Which is Apple’s HE should go way.  Fast fallback is really all that is needed.  Measuring RTT and using that to decide which family to use doesn’t actually make it easier to decide when one can switch off IPv4. We need a bias towards IPv6 so that, in the absence of packet loss, traffic will use IPv6 99.999% of the time when there is a choice.

> In some situations local communication isn't allowed anyway and in others I'm fine with IPv4 link-local until IPv4 can be turned off by implementing layer 2 filtering and/or draft-ietf-6man-ipv6only-flag.

> In many environments what you say is true, especially where you have control of the devices, we have done it in many experiments too. But in public access BYOD environments, I think you need some way to measure the issue. Large networks will probably never get to zero IPv4 usage, but if you can measure you can decide when it is in the noise or it is a small enough hit you are willing to take. 

For BYOD we are essentially there with DNS64 today.  DNS64/NAT64 works for most things even VPN’s provided you encapsulate in UDP.

For other IPv4AAS you need to measure which DHCPv6 options are being set.  In many cases it will be try it and be prepared to back out if it causes too much trouble.  Repeat in 6/12 months as the device population will change.

---

From: David Farmer <[email-masked]>
Date: Fri, 26 Oct 2018 13:45:33 -0500

On Thu, Oct 25, 2018 at 7:23 PM Mark Andrews <[email-masked]> wrote:

> > > So, how is a network operator to determine if IPv4 routing is needed
> on a link network? Right now most dual-stack hosts will happily take and
> use an IPv4 address if DHCPv4 gives them one, whether or not they actually
> need it or not. So, the only way to know for sure that IPv4 routing is
> needed on a link network or not is to turn it off and see if anyone
> SCREAMS! While I believe we need Layer 2 filtering and
> draft-ietf-6man-ipv6only-flag, it seems to me, we need something else too.
> We need something to determine if IPv4 routing is actually needed on a link
> network in the first place.
> >
> Well if you don’t care about DNSSEC, DNS64 gets you 99.9% of the way
> there.  It is a IPv4AAS for sites reached by name.  For lots of nets it
> will just be disable IPv4 and see what breaks. You can alway reverse the
> decision and then address the issue that caused you to go back.
>

I'm actually a little shocked that you think DNS64 qualifies as good enough
based on previous threads. I think it's close to good enough, I'd rather
not compromise on DNSSEC, so I'd like to see
draft-pref64folks-6man-ra-pref64 move forward.

For most of my link networks "try it and see what breaks" is just fine.
However, our WiFi has over 70,000 users with approximately 30,000
concurrent users. So for WiFi, I'd like to have better info about the level
of expected breakage before even trying.  "Try it and see how many breaks"
is not a plan I can sell for our WiFi. No, it's not just one big Layer2, it
is 30 or more segments.

I'm also thinking about how to profile hosts and put them on IPv6-only
segments. If I've never seen the host before I put them on an IPv4/IPv6
dual-stack network for enrolment. If they don't configure their IPv4
address in the future I can put them on an IPv6-only network, otherwise, I
put them on an IPv4/IPv6 dual-stack network

Thanks

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Oct 2018 21:27:52 +0200

> put them on an IPv4/IPv6 dual-stack network

If you can orchestrate your WiFi to do this, great. If this is even a
standard feture of your vendors WiFi solution (without you having to do
a good amount of manual decisions or scripting/customization), even better.

But: That layer of work is not contradicting the draft, but the draft
would actually be complementary:

Just putting a node on an IPv6 only network does not help (AFAK) to
prohibit hosts to try to configure IPv4 and continuously run the
signaling for IPv4 link-local addresses. As said in a prior mail, i
think that AP-level filtering can minimie the battery impact, but it
would not stop nodes attempting it. This discussed draft can stop them
attempting it.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Oct 2018 06:51:03 +1100

> On 27 Oct 2018, at 5:45 am, David Farmer <[email-masked]> wrote:
> 
> 
> I'm actually a little shocked that you think DNS64 qualifies as good enough based on previous threads. I think it's close to good enough, I'd rather not compromise on DNSSEC, so I'd like to see draft-pref64folks-6man-ra-pref64 move forward.

Well I did say if you don’t care about DNSSEC.  I want to see pref64folks-6man-ra-pref64 move forward
as well.

> For most of my link networks "try it and see what breaks" is just fine.  However, our WiFi has over 70,000 users with approximately 30,000 concurrent users. So for WiFi, I'd like to have better info about the level of expected breakage before even trying.  "Try it and see how many breaks" is not a plan I can sell for our WiFi. No, it's not just one big Layer2, it is 30 or more segments.  

Well configure a NAT64 and DNS64 and see what IPv4 traffic still flows.  With DNS64 in BIND you can tell the DNS64 to not break DNSSEC for clients that set DO=1 (it is the default setting).  You don’t have to turn off IPv4 to turn on NAT64 and DNS64.  The default address selection rules should move almost all of the IPv4 traffic to using the NAT64 (except potentially the Apple devices where Apple decided !@#$! with the IPv6 bias we know best when they actually don’t).

> I'm also thinking about how to profile hosts and put them on IPv6-only segments. If I've never seen the host before I put them on an IPv4/IPv6 dual-stack network for enrolment. If they don't configure their IPv4 address in the future I can put them on an IPv6-only network, otherwise, I put them on an IPv4/IPv6 dual-stack network   

There is nothing to tell a host DO NOT configure IPv4 for almost all attachment methods.

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Oct 2018 11:38:07 +0200

Dumb question: Jordi and others have been pushing drafts on IPv6-only operation and IPv4aas in otherwise IPv6-only networks in v6ops. It sounds like you're looking for a unifying draft. What issues would you recommend be covered in it? Is this 6man or v6ops?

On Oct 25, 2018, at 7:56 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I think this is an excellent suggestion. However, I don't think 6man might be the best place to have this discussion. To get proper attention to the problem as an operational problem statement, one thought would be to ask if v6ops could work on this problem and add it to its charter?
> 
> --

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Oct 2018 19:14:58 +0200

> On Oct 25, 2018, at 11:58 PM, Mark Andrews <[email-masked]> wrote:
> 
> Turning off IPv4 will ALWAYS be a judgement call.
> 
> Is IPv4AAS available?

You might enjoy a conversation with Cameron Byrne. He is running 464XLAT as an IPv4aas implementation in T-Mobile. He indicates that in the T-Mobile network, traffic that isn't IPv6-native is pretty sparse. My guess is that the fact reflects either the applications on a telephone, which probably primarily use HTTP transport, or the services people go to. In Trinidad and Tobago, each of the major sources of statistics say that there is a high proportion of IPv6, and that part of the reason is that Google, Facebook, and other common services are IPv6-only. I'm told the same thing in Reliance JIO, which is both a mobile and a residential network.

Yes, turning off IPv4 is a judgement call. People are always asking what the business case for IPv6 is. I'm talking with a network startup (that I won't name) about connecting some 5000 primary and secondary schools to the Internet and providing some services to them. Now, they could purchase them at $14-20 per address, which is to say "spend $17-25M", or they could get one IPv6 /32 prefix for the network at $2100 annually (LACNIC posted price). To my mind, it's a pretty straightforward business case. If it were my enterprise or my network, I would target doing what MIT did - selling any IPv4 address space I had an using it to fix my network and applications. That sounds like a large return on investment.

> Begin forwarded message:
> 
> From: Ca By <[email-masked]>
> Subject: Re: [v6ops] Trajectory for "transition" mechanisms in our working group
> Date: October 18, 2018 at 3:31:02 PM GMT+2
> To: Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]
> 
> Tl,dr; CLAT likely does not need acceleration since it should not see much traffic.
> 
> The reason CLAT is so enjoyable in my deployment of 464xlat with DNS64 is that CLAT only handles very few flows that use ipv4 literals or force ipv4 socket by other means.
> 
> In the home, their is a great varitety of things that behave in many ways, but i would have to assume the typical windows 7+ / ios10+ home at this point is mostly ipv6 traffic. We certainly see Google’s overall number is 35% in the usa, and most of that traffic is Youtube, FB, Netflix ... with v6 ... and many things ask for AAAA and could receive it and therefore leverage standard ipv6 routing on the CPE with no special treatment at the edge

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Oct 2018 16:35:02 -0400

> On Oct 26, 2018, at 2:45 PM, David Farmer <[email-masked]> wrote:
> 

I would like to see pref64 move forward if only because there are certain faults that can happen with RFC 7050 that shouldn't happen with it. That said, I still don't understand the argument about it affecting DNSSEC.

DNSSEC, in this case, would be applied to A and AAAA records originated by the party maintaining the machine. If a AAAA record exists (and therefore might have a DNSSEC record), DNS64 by definition doesn't concoct a AAAA record. So, if I ever receive a DNS64-generated AAAA record, there was no DNSSEC-signed record to compromise. Hence, DNS64 doesn't compromise DNSSEC.

Yes, people could do something like suppress the delivery of some set of DNSSEC records, and as a result enable themselves to do that which DNSSEC is a mitigation against - changing or creating fallacious records. I don't know that DNSSEC actually counters that; if the resolver never receives a signature to verify it, I don't see how it knows that the signature exists or that one with a different key is invalid. But that's not about DNS64; it's about people intentionally messing with DNS.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Oct 2018 07:56:29 +1100

> On 27 Oct 2018, at 7:35 am, Fred Baker <[email-masked]> wrote:
> 
> 
> 

A DNSSEC validator rejects synthesised records if the zone is signed and is treated as secure by the validator.  DNSSEC stops you adding, removing or changing RRsets in a secure zone from the validator’s perspective.

> Yes, people could do something like suppress the delivery of some set of DNSSEC records, and as a result enable themselves to do that which DNSSEC is a mitigation against - changing or creating fal…

If a answer arrives without valid RRSIG records (alway true for DNS64 synthesis) the validator has to prove the answer comes from a insecure zone from the validators perspective.  That means there is a) not a trust anchor configured above that name of the RRset or b) there is a insecure delegation between the trust anchor found and the name of the the RRset being validated.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Oct 2018 23:42:06 +0200

--> If there is already an AAAA record, DNS64 will note synthetize it, so nothing broken.

--> The validation is only broken if it is done by the "end host" (the one using the DNS64 AAAA synthetized response).

For example, if the validation and the synthesis are done together in the end host, then nothing breaks, because the end host will perform the validation with the A record, not the AAAA one (which it knows is synthetized). A DNS server which is DNS64-aware, will do the same, but he doesn't know "for sure" if an end host behind it will try to validate the AAAA.

I will suggest reading 4.1.  DNSSEC Considerations and Possible Approaches on draft-ietf-v6ops-nat64-deployment for a more detailed explanation of this.

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 27 Oct 2018 06:53:42 +0200 (CEST)

On Fri, 26 Oct 2018, Fred Baker wrote:

> Dumb question: Jordi and others have been pushing drafts on IPv6-only 
> operation and IPv4aas in otherwise IPv6-only networks in v6ops. It 
> sounds like you're looking for a unifying draft. What issues would you 
> recommend be covered in it? Is this 6man or v6ops?

Well, I don't know if it needs to be a unifying draft (could be), but 
something talking about what hosts should do with their IPv4 stacks when 
there is no native IPv4 on the link (for some definition) could be either 
a new draft or included in some other draft. It's going to be a hard 
problem to work on with lots of opinions though.  It would also require 
actual OS vendor participation because they have knowledge about use-cases 
most of us here in 6man/v6ops probably don't think about (like the "let's 
connect to a printer wifi which might use ipv4 link-local" use-case).

I don't see this document suited for 6man, so it'd have to be v6ops 
because I don't see any other working group where it would be suited.

I base this opinion on my experience in bringing things into INT-AREA and 
then it not receiving any attention, even for things I know v6ops peeps 
care a lot about that would generate lots of discussions there.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Oct 2018 16:11:57 +0100

The ipv6only draft/flag is certainly in the context of evolving to
ipv6only (subnet) operations. And as i said, to me thats a value even
if we ignore all specific wifi benfits.

You certainly point to the bigger problem of network operator
determining when to "disable IPv4", but IMHO, the procedures for the
v6only flag are equally applicable to the case where you do not even
have that choice to make: You just have a router with external IPv6only
connectivity.

In that case still you can have IPv4only hosts on the LAN such as million
of consumer equipment devices. Of course, this may only be a problem of
one more decade (i hope), but maybe still worth addressing.

I think a router configured for only IPv6 on a subnet (e.g.: because of
only external IPv6 connectivity) could even automatically figure out
how to set the v6only flag, and hosts could also automatically react:

router discovers/tracks v4only hosts. Aka: arp/dhcp/.. and filter those
hosts that also have ipv6 (from MAC address). Maybe to standardize we
could define a YANG data model representing how to keep track of
appropriate messages by MAC-addrss. This module could make sense all
by itself just to monitor LANs and discover legacy equipment in the NOC.

So, whenever router sees IPv4only hosts, it could automatically unset
v6only flag and otherwise set it. dual-stack hosts understanding the
flag would enable/disable their v4 stack accordingly. v4only printer is
switched on, dual-stack hosts enable ipv4, printer switched off, flag
will be set again by router, ipv4 gets disabled.

I don't think this is all that difficult, after all, we're really only
talking about deciding whether to have any link-local ipv4 enabled or
not. As soon as there is any global-scope IPv4 in play, its a different
discussion. 

Toerless