Subject: Fwd: New Version Notification for draft-hinden-ipv4flag-02.txt

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Feb 2018 12:25:56 -0800

We did an update to this draft.  Changes were to improve the text and clarify the intent of the draft.

Please review and comment.

Thanks,
Bob & Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-ipv4flag-02.txt
> Date: February 15, 2018 at 12:19:08 PM PST
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <[email-masked]>, "Brian Carpenter" <[email-masked]>
> 
> 
> A new version of I-D, draft-hinden-ipv4flag-02.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-ipv4flag
> Revision:	02
> Title:		IPv6 Router Advertisement IPv4 Unavailable Flag
> Document date:	2018-02-15
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-02
> 
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate to
>   hosts that there is no IPv4 service on the advertising default IPv6
>   router.  This document updates RFC5175.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Feb 2018 11:05:09 -0800

At Thu, 15 Feb 2018 12:25:56 -0800,

> Please review and comment.

I've read draft-hinden-ipv4flag-02.  Personally I'm not yet convinced
that a "no IPv4 service" signal is necessary or that (assuming it's
necessary) (ab)using IPv6 RA is the best way to do that.  But I don't
have a strong reason to say this is really a bad idea either.  So I'm
neutral about the proposal itself.  I'm just making some
mostly-editorial comments below (I found it generally well written).

- Section 1

   [...]  The flag does not apply to non-default IPv6 routers.

  On first read it was difficult to me to understand what it means.
  I'm not sure if I can suggest anything obviously better, but perhaps
  this may be a bit more understandable:

    The flag does not apply to nodes sending router advertisement but
    are not an IPv6 default router.

- Section 2

   Hosts receiving the Router Advertisement should only process this
   flag if the advertising router is a Default Router.  Specifically, if
   the Lifetime field in the Router Advertisement is not zero, otherwise
   it should be ignored.  This is done to allow some IPv6 routers to
   advertise information without being a Default Router and providing
   IPv6 connectivity.

  The second and third sentences were difficult to understand for me:
  the 'if' clause in the second sentence is incomplete; "This" in the
  third sentence is ambiguous.  I'd suggest rephrasing the last 2
  sentences (e.g.) as follows:

   [...] Specifically, if the Lifetime field in the Router
   Advertisement is zero, the IPv4 Unavailable Flag should be ignored.
   Such a Router Advertisement can be used to allow some IPv6 nodes to
   advertise information without being a Default Router or providing
   IPv6 connectivity.

- As a related note, what if an IPv6 default router becomes
  a non-default router by sending an NA with R flag being off (and
  perhaps just stopping sending RAs)?  According to the overall
  description of the draft, I guess the host should treat the NA
  sender same as an RA sender that sets the router lifetime to 0.
  Perhaps it's considered too obvious and omitted, but you may want to
  note it explicitly to be more comprehensive.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Feb 2018 11:23:06 -0800

> On Feb 16, 2018, at 11:05 AM, 神明達哉 <[email-masked]> wrote:
> 
> necessary) (ab)using IPv6 RA is the best way to do that.

I'm of a similar opinion; the fact that a router is an IPv6 router doesn't, to me, imply that it knows anything at all about IPv4 routing, especially if the routing is static and therefore not determinable by routing traffic. This is something that would have to be configured to ensure its correctness (the operator would know about static routing, for example).

>    are not an IPv6 default router.

Given that I believe that configuration is required, I tend to think the observation doesn't make sense. It applies if and only if it is configured, and it will apply to every router on which it is configured. I might make sense to advise the operator to not configure it on non-default routers, but at most I would expect it's a correctness edit at configuration time.

>  note it explicitly to be more comprehensive.

I think the case is important, if only because I think the flag has to be configured. So now we are identifying a configuration that expresses the intent of the operator but becomes invalid due to a change of some kind.

---

From: james woodyatt <[email-masked]>
Date: Fri, 16 Feb 2018 12:32:54 -0800

> Please review and comment.

While I don’t think this new revision of the draft has any glaring technical problems, I remain unconvinced that it would be either appropriate or necessary to signal the unavailability of IPv4 forwarding service in IPv6 Router Advertisement messages.

I think I’d prefer to see an IPv4 sunset mechanism that expands Address Resolution Protocol (ARP) [RFC 826] to signal indications of IPv4 service limitations to IPv4 hosts. For example, I could see IPv4 hosts processing ARP packets containing assertions that the DHCP multicast group does not have a hardware address as an indication that DHCP discovery is unlikely to succeed. Similar methods could be used to signal that IPv4 link-local communication is forbidden, e.g., for mDNS, et cetera. A special purpose “evacuate all IPv4 hosts” address could be defined to signal with an ARP assertion that all IPv4 hosts should halt all IPv4 transmission.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 17 Feb 2018 13:37:27 +1300

On 17/02/2018 08:23, Fred Baker wrote:
> I'm of a similar opinion; the fact that a router is an IPv6 router doesn't, to me, imply that it knows anything at all about IPv4 routing, 

And that's why the flag, if set, means "I don't do IPv4 routing". Nothing more, nothing less.

> especially if the routing is static and therefore not determinable by routing traffic. This is something that would have to be configured to ensure its correctness (the operator would know about static routing, for example).

Yes, but *this* router has nothing to do with that.

     Brian

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

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 17 Feb 2018 13:43:22 +1300

> I think I’d prefer to see an IPv4 sunset mechanism that expands Address Resolution Protocol (ARP) [RFC 826] to signal indications of IPv4 service limitations to IPv4 hosts. For example, I could see…

(Not in this WG, though.) Are we really going to propose IPv4 stack modofications? Is that likely to get any traction?

The ipv4flag proposal is to mitigate, not solve, the issue of redundant IPv4 traffic. I think it fits the "first, do no harm" principle because if a host ignores it, no new harm results. And it's addressed not to the IPv4 part of the stack, but to the control logic that lies above.

     Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Feb 2018 13:11:12 +1100

> Yes, but *this* router has nothing to do with that.

I suppose it depends on what the function or functions of an RA is.

I've thought the name "Router Advertisement" has been fairly
inaccurate, as it hasn't really be advertising many properties
specific to the router itself - I think router lifetime is the only
one. Nearly all others are link specific layer 3 IPv6 parameters that
aren't specific to the router advertising them, e.g. MTU, ND
parameters, link specific IPv6 prefixes in PIOs etc., although RFC8028
more tightly couples PIO prefix announcement with a specific router's
forwarding service.

The name has probably carried over from the IPv4 RAs in RFC1256, where
RAs were explicitly about the router itself and nothing more. A more
accurate name for IPv6 RAs could be something like "IPv6 Link
Configuration Advertisement" or perhaps "IPv6 Subnet Configuration
Advertisement". (DNS options in RAs further dilutes the name accuracy
- they're not parameters specific to and only valid on a specific
link.)

On the other hand, this flag is going down the path of having an RA
also announce router specific capabilities to the hosts. It reminds me
of the OSPF Options field carried in Hellos etc. that announces the
router's OSPF supported capabilities.

An argument against doing it would be that IPv6 protocols shouldn't
know or do anything related to IPv4. However, that has already
happened by allowing IPv4 DNS A RRs to be carried in IPv6 carried DNS
queries, or allowing IPv4 NLRI be carried over IPv6 BGP sessions.

I think it is reasonable to do what is being proposed here - it is an
explicit statement that this IPv6 router doesn't support or have
enabled IPv4, and if all routers on the link announce that, then it is
an explicit statement to hosts that they don't need to enable IPv4
unless they themselves have a specific reason to.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Feb 2018 21:40:22 -0800

> On Feb 16, 2018, at 4:37 PM, Brian Carpenter <[email-masked]> wrote:
> 

That only requires that it not advertise IPv4 routing protocols. A router that advertises no routing protocols and isn't specified in DHCP as a first hop selection will not be used to route IPv4 traffic. Nobody knows to try it.

So the flag is specifying something the host already knows.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Feb 2018 07:54:06 -0800

Mark,

> On Feb 16, 2018, at 6:11 PM, Mark Smith <[email-masked]> wrote:
> 

That is the intent of this draft.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Feb 2018 08:03:25 -0800

Fred,

> On Feb 16, 2018, at 9:40 PM, Fred Baker <[email-masked]> wrote:
> 
> 
> 

These are things that the host can deduce after some time period, that is, if it doesn’t hear anything or get any responses.  The proposed mechanism gives the host information it can act on affirmatively.  Of course, it’s not just about routing, it’s about giving the hosts information so they can stop auto-configuring IPv4 addresses and attempting to reach IPv4 services if they choose.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Feb 2018 08:14:22 +1300

> These are things that the host can deduce after some time period, that is, if it doesn’t hear anything or get any responses.  The proposed mechanism gives the host information it can act on affirma…

Also, one way hosts can use this flag is to simply reduce the frequency
of polling for IPv4 service. This will reduce wasted battery power for all
nodes on the link, not just for the host concerned, without preventing
IPv4 completely.

    Brian

---

From: Simon Hobson <[email-masked]>
Date: Tue, 20 Feb 2018 12:49:41 +0000

> These are things that the host can deduce after some time period, that is, if it doesn’t hear anything or get any responses.  The proposed mechanism gives the host information it can act on affirma…

I'm not sure you can be so bold.
All the IPv6 routers saying that they aren't doing IPv4 doesn't actually mean that there aren't any IPv4 routers on the network. So even if every IPv6 router sets this flag, the host must still assume that IPv4 may be available/required - so it's hard to see exactly where the benefit lies.

IMO the only way round this is to mandate that the network operators MUST configure this manually on all routers to reflect the situation in their network. Ie, change it from being a hint (I don't have it, I don't know if anyone else has), to being a definitive statement (I know that no-one on this network has it) - but down that route lies another large can of worms.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Feb 2018 15:25:41 +0100

Le 20/02/2018 à 13:49, Simon Hobson a écrit :
>>> That only requires that it not advertise IPv4 routing protocols.
>>> A router that advertises no routing protocols and isn't specified
>>> in DHCP as a first hop selection will not be used to route IPv4
>>> traffic. Nobody knows to try it.
>>> 
>> These are things that the host can deduce after some time period,
>> that is, if it doesn’t hear anything or get any responses.  The
>> proposed mechanism gives the host information it can act on
>> affirmatively.  Of course, it’s not just about routing, it’s about
>> giving the hosts information so they can stop auto-configuring IPv4
>> addresses and attempting to reach IPv4 services if they choose.
> 
> I'm not sure you can be so bold. All the IPv6 routers saying that
> they aren't doing IPv4 doesn't actually mean that there aren't any
> IPv4 routers on the network. So even if every IPv6 router sets this
> flag, the host must still assume that IPv4 may be available/required
> - so it's hard to see exactly where the benefit lies.
> 
> IMO the only way round this is to mandate that the network operators
> MUST configure this manually on all routers to reflect the situation
> in their network. Ie, change it from being a hint (I don't have it, I
> don't know if anyone else has), to being a definitive statement (I
> know that no-one on this network has it) - but down that route lies
> another large can of worms.

Routers must listen to each other's RA, so we could also say that if a 
Router hears an ipv4lag on a link it should set its own.

Alex

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Feb 2018 08:17:09 -0800

Simon,

> On Feb 20, 2018, at 4:49 AM, Simon Hobson <[email-masked]> wrote:
> 

The intent is that this flag would be enabled if the admins want to tell the hosts there isn’t IPv4.  The intent is not that the routers make their own decision given what else is configured on the router.

I think the common case is that most routers are dual stack and under a single administration.  We don’t claim this is useful in every imagined situation, but think it is useful in a lot of places where there is a desire to only run IPv6.  For example, the IETF IPv6 only SSID.  In other environments, don’t use it.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Feb 2018 16:58:17 +0000

> On 20 Feb 2018, at 16:17, Bob Hinden <[email-masked]> wrote:
> 
> Simon,
> 

This is an interesting draft. I can see how it could be useful for a host to have an additional *hint* that it may wish to stop sending DHCPv4 requests earlier than it otherwise would, as described in the draft, and to help reduce unnecessary network chatter. The examples listed in rationale section are quite compelling.

But in practice such a flag would need to be used with a lot of care. The case of IPv4 mDNS/DNS-SD is perhaps tricky. Currently, a dual-stack host will mirror SD traffic in IPv4 and IPv6, replicating SD traffic over both.  Yet two hosts in an 'IPv6 only' network might have an application that is IPv4-only, that could work via IPv4 LLs, but turning off IPv4 SD would break that (albeit an application that should be ported to IPv6!).

Ultimately the benefit only comes if IPv4-specific behaviour (and code) is changed. Have any vendors indicated that they would adapt IPv4 configuration behaviour based on the existence of such a hint flag in an RA?  And if so, which of the behaviours of section 4 would they follow?  IPv4 off completely?  IPv4 with just LLs?  IPv4 with longer intervals between messages such as DHCP requests?

As an aside, what's the current mechanism to tell a host what NAT64 prefix it should use for 464XLAT?  I recall a DHCPv6 option was proposed, but is that draft alive?  If it were conveyed in an RA, that might also be taken as a hint of no IPv4 support in the network, at least from the router issuing the RA.

This should all be easier with PvDs...

Tim

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 20 Feb 2018 16:58:57 +0000

> Routers must listen to each other's RA, so we could also say that if a Router
> hears an ipv4lag on a link it should set its own.

That sounds like a good suggestion for creating a DoS feature. All someone would have to do to bring down IPv4 in a network is introduce a single piece of malware that claims to be a router and sets the ipv4flag.
Barbara

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Feb 2018 10:04:33 -0800

> All the IPv6 routers saying that they aren't doing IPv4 doesn't actually mean that there aren't any IPv4 routers on the network. So even if every IPv6 router sets this flag, the host must still ass…

That was my opening remark on this topic.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 07:27:24 +1300

>> - so it's hard to see exactly where the benefit lies.

Simon: As I said earlier, it depends on the host's specific stack
and operational requirements; IMHO a likely implementation would
simply be to significantly reduce the frequency of polling for IPv4
service, thereby saving battery power for *all* hosts on the link.

>> another large can of worms.

I don't advocate this approach. It will fail anyway because of legacy
routers.

> Router hears an ipv4lag on a link it should set its own.

Alex: No. The flag says "I don't provide IPv4 routing". Each router
knows its own IPv4 status.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 07:33:20 +1300

> But in practice such a flag would need to be used with a lot of care. The case of IPv4 mDNS/DNS-SD is perhaps tricky. Currently, a dual-stack host will mirror SD traffic in IPv4 and IPv6, replicati…

Right, but this flag doesn't turn anything off. Again: it only says "I don't route IPv4."
Hosts that want to use any on-link IPv4 service are at liberty to do so. I thought the
draft made that clear, but maybe we need to add some words.

> Ultimately the benefit only comes if IPv4-specific behaviour (and code) is changed. Have any vendors indicated that they would adapt IPv4 configuration behaviour based on the existence of such a hi…

As I said - it depends on the stack and on the host's requirements. It's fail-safe;
ignore this flag and nothing bad happens.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 07:36:03 +1300

> That was my opening remark on this topic.

And it's addressed both by the draft and by other responses in this thread.

To put it another way: do you want all battery powered devices to waste
electricity polling for IPv4 and receiving such polls for ever?

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Feb 2018 19:28:28 +0000

> On 20 Feb 2018, at 18:33, Brian E Carpenter <[email-masked]> wrote:
> 

The draft says in Section 4 that "a host that receives only RAs with the flag set to 1 may choose not to attempt any IPv4 operations. That sounds like turning IPv4 off, albeit is a 'may'.

In practice, I think the option in the paragraph below is the most useful way to interpret the flag - "a host that receives only RAs with the flag set to 1 may choose to attempt IPv4 operations but at significantly lower frequency than normal".

> As I said - it depends on the stack and on the host's requirements.

The problem is how the host knows specifics of the environment that it's in, to decide which option to follow.

> It's fail-safe; ignore this flag and nothing bad happens.

That much is true :)

Tim

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Feb 2018 06:34:21 +1100

> And it's addressed both by the draft and by other responses in this thread.

I think another way to describe this could be to help the dual hosts
about IPv4 status on the link when they don't know better.

So, if a dual stack hosts are ambivalent about IPv4, they would
currently assume it is required and trigger DHCPv4. If all of the IPv6
routers, in combination, are saying, "this is an IPv6 only link", then
the ambivalent IPv4 host would now know not to perform DHCPv4. On the
other hand, if the host knows it needs IPv4, then it would trigger
DHCPv4 regardless.

A further thought I've had regarding the Host Behavior Considerations
scenarios is that a host that is receiving all RAs with this flag
could delay performing DHCPv4 until it gets a request form an
application to use IPv4 (e.g. a Sockets API connect() call), and block
returning that call until the DHCPv4 transaction is complete. So if
there are no IPv4 using applications, there is no DHCPv4.

Perhaps that could be more general advice. The host doesn't perform
any IPv4 address acquisition (i.e. DHCPv4) until an application
expresses a need for IPv4. Currently hosts are assuming they need
IPv4, regardless of whether they have an application that needs it or
not. IPv4 would move to be being established on-demand upon startup of
the first IPv4 application.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Feb 2018 12:33:38 -0800

Hi Brian,

You sent two messages about three minutes apart containing the following excerpts which leave me confused reading them together.

On Feb 20, 2018, at 10:33, Brian E Carpenter <[email-masked]> wrote:
> [...]

On Feb 20, 2018, at 10:36, Brian E Carpenter <[email-masked]> wrote:
> [...]
> To put it another way: do you want all battery powered devices to waste electricity polling for IPv4 and receiving such polls for ever?

If the flag “doesn’t turn anything off” then how does it stop battery powered devices from wasting power “polling for IPv4” [and waiting] “for ever?”

If the authors could add some words about that maybe it would help build support.

--james woodyatt <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 10:10:14 +1300

> If the authors could add some words about that maybe it would help build support.

It's very much a matter of choice for the implementor of the device and the sort
of scenarios where the device is expected to be installed. So yes, I can see that
the wording could be better on this point.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 10:13:43 +1300

> The draft says in Section 4 that "a host that receives only RAs with the flag set to 1 may choose not to attempt any IPv4 operations. That sounds like turning IPv4 off, albeit is a 'may'.

I can see from this comment and some off-list comments that this "may" is confusing
people. It's intended to be English, not RFC2119ish, but perhaps it needs to
be "might". Certainly the intention was not to imply anything more.
> In practice, I think the option in the paragraph below is the most useful way to interpret the flag - "a host that receives only RAs with the flag set to 1 may choose to attempt IPv4 operations but…

Very likely, but I think that's an impelementation choice.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Feb 2018 11:53:53 +1300

> routers, in combination, are saying, "this is an IPv6 only link", then

But that is not what the bit means. It's *only* meaning is "I don't
route IPv4." It says nothing about the link as a whole.

> other hand, if the host knows it needs IPv4, then it would trigger

Exactly. The proposal doesn't change that. It's just input to whatever
heuristic the host uses to determine its IPv4 behaviour.

> there are no IPv4 using applications, there is no DHCPv4.

Exactly. That sounds like a useful heuristic.

> the first IPv4 application.

Good point. BTW, what is an "IPv4 application", especially if there's
NAT64/DNS64 on the link?

    Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 20 Feb 2018 23:04:14 +0000

Section 2:

      4    IPv4 Unavailable Flag [RFC4861<https://tools.ietf.org/html/rfc4861>]

I don't understand the reference to RFC4861 here? Is it appropriate? Why? I think this should be removed.

-          Bernie

From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, February 15, 2018 3:26 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Fwd: New Version Notification for draft-hinden-ipv4flag-02.txt

Thanks,
Bob & Brian

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hinden-ipv4flag-02.txt
Date: February 15, 2018 at 12:19:08 PM PST
To: "Robert M. Hinden" <[email-masked]<mailto:[email-masked]>>, "Robert Hinden" <[email-masked]<mailto:[email-masked]>>, "Brian Carpenter" <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Feb 2018 15:13:07 -0800

Bernie,

> On Feb 20, 2018, at 3:04 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Section 2:
> 
>       4    IPv4 Unavailable Flag [RFC4861]
> 
> I don’t understand the reference to RFC4861 here? Is it appropriate? Why? I think this should be removed.

Good point, a reference for the new bit should point to this document.

Thanks,
Bob

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 20 Feb 2018 23:13:43 +0000

Is there any recommendation to add to this document that if a host does "disable" IPv4, it probably should keep the loopback interface (127.0.0.1)? Any recommendations based on this new flag should be restricted to off host IPv4 traffic (on that interface). Not to the host's support of IPv4 in general?

The word "interface" doesn't appear in the draft and it may want to be clear about RAs received on different interfaces vs the same interface?

For example:

   If there are multiple IPv6 default routers on a network, they might
   send different values of the flag.  If at least one IPv6 default
   router sends the flag with value 0, a dual stack host should assume
   that IPv4 is available.  If all IPv6 default routers send the flag
   with value 1, a dual stack host may assume that IPv4 is not
   available.

This is presumable on a SINGLE interface (multiple default routers). Perhaps that is what the "on a network" is intended to mean.

-          Bernie

Thanks,
Bob & Brian

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Feb 2018 16:39:40 -0800

Bernie,

> On Feb 20, 2018, at 3:13 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Is there any recommendation to add to this document that if a host does “disable” IPv4, it probably should keep the loopback interface (127.0.0.1)? Any recommendations based on this new flag should be restricted to off host IPv4 traffic (on that interface). Not to the host’s support of IPv4 in general?
> 
> The word “interface” doesn’t appear in the draft and it may want to be clear about RAs received on different interfaces vs the same interface?
> 
> For example:
> 
> This is presumable on a SINGLE interface (multiple default routers). Perhaps that is what the “on a network” is intended to mean.

I think “default routers on a link” would be better and make this clearer.

Agree?

Thanks,
Bob

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 21 Feb 2018 01:23:04 +0000

Yes, that sounds good.

- Bernie (from iPad)

> On Feb 20, 2018, at 7:39 PM, Bob Hinden <[email-masked]> wrote:
> 
> Bernie,
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 21 Feb 2018 22:54:31 +0900

> there are no IPv4 using applications, there is no DHCPv4.

I don't think that's feasible. In general you can't connect until you do a
DNS lookup, and in that DNS lookup you need to decide whether to ask for A
records or not.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 21 Feb 2018 11:50:13 -0800

At Mon, 19 Feb 2018 08:03:25 -0800,

> addresses and attempting to reach IPv4 services if they choose.

Would it help if we changed the meaning of this bit to "whether this
node acts as a DHCPv4 server (or relay agent)", thereby just focusing
on reducing hopeless DHCPv4 DISCOVERs?  It still won't address the
point that we can't be sure if there's a node that doesn't advertise
RA but acts as a DHCPv4 server (I guess some of the concerns on this
draft come from variants of this point), but we can at least avoid
worrying about cases like static IPv4 routing.  It will also be less
likely to discourage the use of IPv4 link-local addresses in an
"IPv6-only" link, but no one can actually prevent it if IPv4
link-local is used for some local p2p applications anyway.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 22 Feb 2018 08:00:33 +1100

On 22 Feb. 2018 12:54 am, "Lorenzo Colitti" <[email-masked]> wrote:

connect() was a rushed example, and it's quite a while since I've done any
sockets programming. It may not have been a good example.

The basic idea is rather than a host assuming applications or services
(e.g. DNS resolver) will need IPv4, and therefore perform DHCPv4 at host
initialisation, wait until the first application or service indirectly
requests it by some AF_INET API call.

At some point in the future, a host would hopefully only have AF_INET6 apps
or services, so would never perform DHCPv4 because AF_INET API calls are
never made.

It would be moving from an IPv4 assumed needed model to an evidence based
on-demand IPv4 model.

It may not be feasible. If it is, I think it would also be moving towards
what the goal of this draft is - to only perform DHCPv4 when there is a
need for IPv4 connectivity and it is available.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2018 16:49:12 +1300

> DNS lookup, and in that DNS lookup you need to decide whether to ask for A

If your DNS server only has an IPv6 address, and further if it's
actually a DNS64, you will never get an A record.

If it's not a DNS64, you may get an A record. If the app chooses to use it,
Mark's suggestion applies.

If you know a DNS server with an IPv4 address, some other process
has already decided to run DHCPv4.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2018 16:53:44 +1300

On 22/02/2018 08:50, 神明達哉 wrote:
> on reducing hopeless DHCPv4 DISCOVERs?

This is an interesting thought, but wouldn't it better to state the
semantic as "This node does not route IPv4 packets and does not
act as a DHCPv4 server or relay" ? I think it's useful to make both
those assertions.

    Brian

> It still won't address the

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Feb 2018 15:06:01 +1100

DNS64 does NOT stop A record lookups succeeding.

All it does is spoof AAAA records under certain conditions.

Mark

> On 22 Feb 2018, at 2:49 pm, Brian E Carpenter <[email-masked]> wrote:
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Feb 2018 17:19:45 +1300

> DNS64 does NOT stop A record lookups succeeding.

Ah yes, I should have said it differently. What I said
applies to apps that actively prefer IPv6.

   Brian

---

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 23 Feb 2018 11:39:19 -0600

> Please review and comment.

I have a hard time thinking the flag is actually useful.  As the draft
acknowledges, filtering ethertypes would work if it came to it.  I would
still think that if a device cares about its battery life, it's vendor 
probably has an incentive to back off on ipv4 discovery. 

When I think about the migrations I worked on from ipx, appletalk,
netbios, to ipv4, it was the application discovery / name service that
was essentially the flags to change behavior, not something from a router.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Feb 2018 12:43:23 +1300

> probably has an incentive to back off on ipv4 discovery. 

Yes, and the flag (or rather the OR of all copies of the flag
if there are several IPv6 routers) is a hint that backing off
IPv4 disvcovery is appropriate. 

> was essentially the flags to change behavior, not something from a router.

Well yes, but this is a bit different - the application discovery method
and the name service are basically the same. If all apps followed the
algorithm of trying IPv6 first and only falling back to IPv4 after a
fairly long timeout, I'm not sure we'd be having this conversation.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Sat, 24 Feb 2018 09:16:37 -0800

> On Feb 23, 2018, at 3:43 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I will add that the flag was set because an administrator wanted it to be sent.  It tells the hosts that that the router sending the RA doesn’t have any IPv4 services and the host can act accordingly.  I think the common case is that there are one or more routers under a common administration.  In cases were there are multiple administrators (that is, a more complicated environment), then this flag doesn’t have to be used.

I think we can have the draft be clearer on this point.

Also, at home I have one router, at work I have two.  Are there environments where the hosts are on links where there are many routers providing different services?  I would think that is pretty uncommon.

Bob

---

From: Ole Troan <[email-masked]>
Date: Sat, 24 Feb 2018 20:03:01 +0100

> Also, at home I have one router, at work I have two.  Are there environments where the hosts are on links where there are many routers providing different services?  I would think that is pretty un…

IPv4 is enabled on a link basis. I don't understand the rationale why this flag isn't making assertions about the link. Like many other RA options.
MTU, PIO...

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Feb 2018 13:08:20 +1300

> IPv4 is enabled on a link basis. I don't understand the rationale why this flag isn't making assertions about the link. Like many other RA options.

As currently defined it will work on a network where there is no coordination between
the various routers, i.e. there is no assumption that the network is managed as a
whole. I think that's fundamentally different from a signal that says "There is
no external IPv4 connectivity anywhere on this link." I assume that if this was
considered realistic, sunset4 would have proposed it already.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 26 Feb 2018 14:10:20 +0900

> actually a DNS64, you will never get an A record.

As Mark said this is not true, DNS64s will happily answer questions for A
records.

> has already decided to run DHCPv4.

I don't think that's sufficient. You only get an A record if you ask for
one, and the problem here is that you don't know whether to ask for one.
See RFC 3494 and AI_ADDRCONFIG.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Feb 2018 10:37:36 +1300

> As Mark said this is not true, DNS64s will happily answer questions for A

Ack
 
> See RFC 3494 and AI_ADDRCONFIG.

Right. If we want to get rid of redundant attempts to use IPv4, we
need to change the incentive that led to Happy Eyeballs. That's
rather orthogonal to the question that this draft raises: do we
want to use up a bit to hint to Happy Eyeballs version 3 (etc.)
that it probably isn't worth trying IPv4?

    Brian

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 26 Feb 2018 16:54:37 -0600

> I will add that the flag was set because an administrator wanted it to be sent.  It tells the hosts that that the router sending the RA doesn’t have any IPv4 services and the host can act according…

What if the routers are under a common administration, but nothing else
is?  In the draft, the host behavior is rather undefined.  If the router
administrators set the flag and hosts correspondingly disable their v4 
stacks, that would also break (ipv4) link-local applications on the
link.

If the hosts were to keep ipv4 link-local working, I think that would be
a more conservative approach where one would be a lot less worried about 
setting the flag.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Feb 2018 12:08:05 +1300

On 27/02/2018 11:54, Dale W. Carder wrote:
> is?  In the draft, the host behavior is rather undefined.

That's a feature, not a bug. The most appropriate behaviour depends
on the device type and the interface type (e.g. it might be different
for Ethernet vs 802.11 vs 802.15.4) as well as the date (the best
strategy in 2018 vs the best strategy in 2028).

>  If the router

Yes. A possible strategy is just to reduce the rate of polling
for IPv4 neighbours, as the draft suggests.

> a more conservative approach where one would be a lot less worried about 

Conservative in what sense? If your goal is to minimise battery usage
"conservative" is to take the "no IPv4 routing" hint very seriously.

The draft is only normative about the meaning of the bit. What hosts
do with it is very much an implementation choice.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 27 Feb 2018 11:03:34 +0900

Wanted to add my 2 cents in favor of this work.

I think I'd change the meaning of the 0 value from:

    0    IPv4 is Available on this default Router

to something more like:

    0    No attestation is made about IPv4 availability on this router
on this link

since it's really only the "all routers advertise a value of 1" that
is of potential interest to a client, I think.

Regarding Ole's "why isn't this a link option like MTU/PIO": I agree
it's a link attribute, but I think it's hard to see the rationale for
burning 64 bits to convey one bit of information (do I have that math
right?).  I do think though that the wording of the meaning of the
bits might clarify that IPv4 availability pertains to this router's
service offering on this link.

I have a client tethering use case in mind where I think this bit
might be useful.

On 16 February 2018 at 05:25, Bob Hinden <[email-masked]> wrote:
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden"
> <[email-masked]>, "Brian Carpenter" <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-02.txt
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-02

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Feb 2018 11:20:38 +0100 (CET)

>    0    No attestation is made about IPv4 availability on this router

I think this is a good compromise between different factors. It's also 
similar to M=0,O=0 which basically means (from my understanding) "I have 
no knowledge that there is DHCPv6 based information/resources available on 
this link".

Nothing prohibits the client to try to do DHCPv6 on the link in this case, 
but the hint is that it's probably not very likely there will be anything 
available.

Same thing here, the IPv4 flag=0 should indicate "From what I know, there 
is no IPv4 on this link".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 Feb 2018 10:28:39 +0000

On 27 Feb 2018, at 10:20, Mikael Abrahamsson <[email-masked]> wrote:
> I think this is a good compromise between different factors. It's also similar to M=0,O=0 which basically means (from my understanding) "I have no knowledge that there is DHCPv6 based information/resources available on this link".
> Nothing prohibits the client to try to do DHCPv6 on the link in this case, but the hint is that it's probably not very likely there will be anything available.

Or indeed the PIO L-bit: "When set, indicates that this prefix can be used for on-link determination.  When not set the advertisement makes no statement about on-link or off-link properties of the prefix."  

> Same thing here, the IPv4 flag=0 should indicate "From what I know, there is no IPv4 on this link".

Though a little confusingly the 'IPv4 flag' being 0 means there is IPv4, as it's a non-availability flag rather than an availability flag.

Tim

---

From: 神明達哉 <[email-masked]>
Date: Tue, 27 Feb 2018 11:12:51 -0800

At Mon, 26 Feb 2018 16:54:37 -0600,

> a more conservative approach where one would be a lot less worried about

BTW, the idea I mentioned about a week ago tried to address the concern:
https://www.ietf.org/mail-archive/web/ipv6/current/msg29489.html

In a sense it's just a wording hack; as long as the host behavior is
(intentionally) left open as implementer's decision, the "meaning" of
the flag doesn't matter much.  But I observed this kind of concerns
were common in this discussion, and I thought if those concerns can be
addressed with some wording hack it might be worth trying as a way to
move forward.

Anyway, it's just a thought just in case it helps.  I'm not intending
to push the idea.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 27 Feb 2018 11:32:34 -0800

At Thu, 22 Feb 2018 16:53:44 +1300,
Brian E Carpenter <[email-masked]> wrote:

> act as a DHCPv4 server or relay" ?

Perhaps, but I also suspect the reference to routing might be more
controversial regarding manual routing (the commonly used response of
"it's just a hint and host can do whatever it wants" doesn't seem to
have convinced people with this kind of concerns).

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Tue, 27 Feb 2018 20:40:52 +0100

> have convinced people with this kind of concerns).

And I think the notion and terminology use of "this device" is problematic.
From the host perspective the IPv4 and IPv6 routers are separate devices.

I'm far from convinced that having an IPv6 router advertise that it is not an IPv4 router adds much value.
Having an IPv6 router state that this is an IPv6 only link, and if any other routers disagree, that's a misconfiguration, would at least be somewhat logically defendable. Not that I'm convinced by the deployability and usefulness of that either...

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Feb 2018 10:57:05 +1300

>     0    No attestation is made about IPv4 availability on this router

That makes no sense to me. An individual router knows whether or not
it supports IPv4 on this link, so it can make that attestation.
I don't see any case where it can't. It's binary, not vague.

> is of potential interest to a client, I think.

Correct, as described in the draft: "the state of the flag as seen by
the host is the logical AND of the flags sent by all unexpired default
IPv6 routers."

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Feb 2018 11:01:01 +1300

> is no IPv4 on this link".

That is not the semantic that Erik defined. It is a bit more than the
draft defines, which is "I don't support IPv4 routing on this link."
We can easily add "I don't support DHCPv4 on this link." You're
suggesting to add "I haven't noticed any IPv4 routing or DHCPv4
traffic on this link." That's much harder to implement.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 09:01:21 +0100

Le 27/02/2018 à 03:03, Erik Kline a écrit :
> 0    No attestation is made about IPv4 availability on this router on
> this link
> 
> it's a link attribute, but I think it's hard to see the rationale
> for burning 64 bits to convey one bit of information (do I have that
> math right?).

If you want to do it minimal, then you need one byte.  That's the
minimal payload of an IPv6 packet.

Of course, you would loose interoperability with much software (radvd),
would need to write new software from scratch, etc.

The 64bit you refer to - I think they are the first 64bits of an ICMPv6
RA.  The others beyond 64bit are optional ('Options').

I think the draft proposes one flag within the existing 64bits of an RA;
the draft does not propose additional 64bits.

I think the RA has to be sent anyways, with that bit set or reset, so I
dont see it as burning.

> I do think though that the wording of the meaning of the bits might
> clarify that IPv4 availability pertains to this router's service
> offering on this link.
> 

What is the tethering use case that might need this bit?

Alex

>> Thanks, Bob & Brian
>> From: [email-masked] Subject: New Version Notification
>> for draft-hinden-ipv4flag-02.txt Date: February 15, 2018 at
>> 12:19:08 PM PST To: "Robert M. Hinden" <[email-masked]>,
>> "Robert Hinden" <[email-masked]>, "Brian Carpenter"
>> <[email-masked]>
>> 
>> 
>> A new version of I-D, draft-hinden-ipv4flag-02.txt has been
>> successfully submitted by Robert M. Hinden and posted to the IETF
>> repository.
>> 
>> Name: draft-hinden-ipv4flag Revision: 02 Title: IPv6 Router
>> Advertisement IPv4 Unavailable Flag Document date: 2018-02-15 
>> Group: Individual Submission Pages: 8 URL: 
>> Status:
>> https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/ Htmlized:
>> https://tools.ietf.org/html/draft-hinden-ipv4flag-02 Htmlized: 
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-02
>> 
>> Abstract: This document specifies a Router Advertisement Flag to
>> indicate to hosts that there is no IPv4 service on the advertising
>> default IPv6 router.  This document updates RFC5175.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 09:04:34 +0100

Le 27/02/2018 à 11:28, Tim Chown a écrit :
>>> 0    No attestation is made about IPv4 availability on this
>>> router on this link
>> 
>> I think this is a good compromise between different factors. It's
>> also similar to M=0,O=0 which basically means (from my
>> understanding) "I have no knowledge that there is DHCPv6 based
>> information/resources available on this link". Nothing prohibits
>> the client to try to do DHCPv6 on the link in this case, but the
>> hint is that it's probably not very likely there will be anything
>> available.
> 
> Or indeed the PIO L-bit: "When set, indicates that this prefix can be
> used for on-link determination.  When not set the advertisement makes
> no statement about on-link or off-link properties of the prefix."
> 
> Though a little confusingly the 'IPv4 flag' being 0 means there is
> IPv4, as it's a non-availability flag rather than an availability
> flag.

'0' - Router advises Hosts MAY make an IPv4 LL
'1' - Router advises Hosts MUST NOT make an IPv4 LL

Alex

> 
> Tim
> 
>> 
>> -- Mikael Abrahamsson    email: [email-masked]
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Feb 2018 09:11:37 +0100 (CET)

> traffic on this link." That's much harder to implement.

I don't agree that's what I said. I didn't mean "I have been tcpdump:ing / 
probing the link for this information and I haven't seen anything". I 
meant it more as "I am not configured to do that" or similar.

---

From: Erik Kline <[email-masked]>
Date: Wed, 28 Feb 2018 17:30:01 +0900

> I don't see any case where it can't. It's binary, not vague.

A node that understands this bit cannot distinguish a value of 0
between the two meanings:

    - I'm a router that does NOT understand this bit and didn't
explicitly set it
    - I'm a router that DOES understand this bit and I set it to 0

I think trying to think of a wording that keeps the meaning the same.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Feb 2018 09:48:02 +0100 (CET)

> I think trying to think of a wording that keeps the meaning the same.

Isn't this motivation to create a new type instead? Or at least use two 
bits to explicitly indicate that the router understands this feature and 
gives indication that it's made an active decision to send this signal?

---

From: Erik Kline <[email-masked]>
Date: Wed, 28 Feb 2018 18:18:58 +0900

On 28 February 2018 at 17:48, Mikael Abrahamsson <[email-masked]> wrote:
> Isn't this motivation to create a new type instead? Or at least use two bits
> to explicitly indicate that the router understands this feature and gives
> indication that it's made an active decision to send this signal?

I don't see the value of going overboard for this.  Seems to me like
the only thing of interest is the value "1" and consuming more space
to say "no I really meant 0 in that bit over there" doesn't seem like
it has much value, to me.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 Feb 2018 16:12:29 +0100

What about the following plan for the long term future (it doesn't do much
for tomorrow):

When a host connects to a link, it only sends a number of RS packets. The
host does not try to configure any kind of IPv4.

If, after some time, the host has not seen any RA, the host assumes that it is
connected to some legacy IPv4 link and configures IPv4.

If a host does see a RA, it initially assumes an IPv6-only link. Only if the
RA has an 'enable-IPv4' bit set, then the host will enable IPv4 as well.

It will take a few years before hosts can assume that IPv6 is the default. So
this approach will not be practical for a while. But long term, 
having a clear 'enable-IPv4' flag is a positive signal that a host should
still bother with IPv4. 

Obviously, there is a bit of a catch that IPv6 routers have to support 
(and operationally set) this flag, before any hosts can switch to this approach.

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 28 Feb 2018 09:38:29 -0600

> '1' - Router advises Hosts MUST NOT make an IPv4 LL

That is very different than the text in the draft:

"A host that receives only RAs with the flag set to 1 may choose not
 to form an IPv4 link-local address.  However, as noted above, if it
 contains link-local applications that can use IPv4, it may instead
 choose to form an IPv4 link-local address ..."

It's this ambiguity on link local that has bothered me.  If the flag is
set to 1 and hosts still do IPv4 link-local discovery, in affect the only
packets saved would be the DHCPv4 requests.  

Dale

---

From: Erik Kline <[email-masked]>
Date: Thu, 1 Mar 2018 09:55:31 +0900

> (and operationally set) this flag, before any hosts can switch to this approach.

I suspect that for regular client operating systems this will not
prove very practical.  There is a lot of pressure to attach to
networks faster, switch networks faster, verify Internet connectivity
(pass captive portal checks) faster...

I think the most likely course of action for a client attaching to a
link for which it has no recorded history (no historical DNA data),
would be to immediately start DHCP'ing and RS'ing, and the best thing
the client can do is look for a signal that says "ok, I'll shutdown
the DHCPv4 client until I detect something that suggests I should
maybe try and start it up again".

Perhaps the presence of IPv4 could be a PvD parameter, in some scenarios.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 15:03:44 +1300

On 28/02/2018 21:04, Alexandre Petrescu wrote:
...
> '1' - Router advises Hosts MUST NOT make an IPv4 LL

No, that is not what the flag means. Please read the draft.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 15:05:36 +1300

> meant it more as "I am not configured to do that" or similar.

OK. But it also means "I have no idea what other routers on this
link might be doing about IPv6, IPv4, IPX, CLNP or Appletalk...".

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 15:07:33 +1300

> I think trying to think of a wording that keeps the meaning the same.

Exactly. It's designed that way. If you set the bit, you are making
a definite statement "I don't do IPv4". If you don't set it, you
are providing no information whatever.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 15:09:37 +1300

> gives indication that it's made an active decision to send this signal?

Not necessary. If it sets the bit, it's made the active decision. That's
all the host needs to know. 

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Mar 2018 15:12:39 +1300

Yes. Write the draft, there's still time before the cutoff.

The -ipv4flag would be a useful hint for such an implementation.

   Brian

On 01/03/2018 04:12, Philip Homburg wrote:
> .