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

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Mar 2018 14:57:31 -0800

We submitted a new version of draft-hinden-ipv4flag.  Link below.  The changes include:

    Changed terminology to use "link" instead of "network”.

    Rewrote the text in Section 4 "Host Behavior Considerations” to make it clearer, and added
    suggestion to only perform IPv4 if an application requests it.

    Added clarification that the bit is set because an administrator configured the router to send it.  The router
    would not set it on it’s own.

    Several editorial changes.

These were done to make the draft clearer based on the discussion on the list.

The diff from previous draft can be found at:

   https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-03

Comments appreciated?

Thanks,
Bob & Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-ipv4flag-03.txt
> Date: March 2, 2018 at 2:50:15 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-03.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-ipv4flag
> Revision:	03
> Title:		IPv6 Router Advertisement IPv4 Unavailable Flag
> Document date:	2018-03-02
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-03
> 
> 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: Mark Smith <[email-masked]>
Date: Sat, 3 Mar 2018 11:10:47 +1100

Hi,

A further thought on this,

"The intent is that the administrator of the router configures the
     router to set the IPv4 Unavailable flag if she/he wants to tell the
     hosts on the link that IPv4 is unavailable.  This is intended to be a
     configuration flag, not something that the router decides on it's
     own."

I think a router could set this flag automatically.

If a router is capable of both IPv4 and IPv6, however only has IPv6 is
enabled on a particular interface (the test could be as simple as "are
there any IPv4 addresses available on the interface"), then it could
automatically set this flag on RAs issued on that interface.

If an IPv4 address is added to the interface (or the interface is
configured to "IPv4 unnumbered") at a later time, then the flag could
then be automatically switched off for subsequent RAs, and an RA would
need to be issued somewhat immediately after the IPv4 interface
configuration event to update the hosts on IPv4 now being available
from this router.

In other words, this flag in an RA follows the state of IPv4
availability on the interface where the RAs are being issued.

Regards,
Mark.

On 3 March 2018 at 09:57, Bob Hinden <[email-masked]> wrote:
>     Added clarification that the bit is set because an administrator
> configured the router to send it.  The router
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden"
> <[email-masked]>, "Brian Carpenter" <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-03.txt
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-03
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Mar 2018 13:28:17 +1300

Mark,

> availability on the interface where the RAs are being issued.

But if the admin *knows* that there is a separate v4 router on
the link, this would be the wrong setting.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 3 Mar 2018 12:52:48 +1100

Hi Brian,

> the link, this would be the wrong setting.

I think the flag definitions are saying this is a statement only about
the RA announcing router's capability, rather than a statement of what
other routers on the link are capable of. That's how I've been
thinking of it. It isn't a universal statement of IPv4 availability on
the link across all routers that is made by one router on behalf of
all or any of the others.

i.e.

 0    IPv4 is Available on this default Router
 1    IPv4 is Not Available on this default Router

As a router specific property, if all IPv6 routers on the link
announce an RA with this "I don't do IPv4" flag set, then a host could
be far more confident that there is no IPv4, and therefore decide not
to perform DHCPv4, unless an IPv4 application requests it.

On the other hand, if only a subset of IPv6 routers announce this
no-IPv4 flag, then a host cannot be as confident about the intended
absence of IPv4, so may choose to perform DHCPv4 even, for example, if
none of its applications request it.

The host would be making a decision on whether to perform DHCPv4 or
not based on the set of information it gets from the set of router
unique RAs it receives, rather than deciding based on the contents of
an individual RA it receives.

Regards,
Mark.