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

From: Bob Hinden <[email-masked]>
Date: Tue, 12 Dec 2017 14:33:46 -0800

Hi,

Based on the discussion on the previous draft, we updated it.  We think this resolves many of the issues raised.  The changes include:

   o  Inverted name of flag from "Available" to "Unavailable”.

   o  Added problem description and clarified scope.

   o  Added router and operational considerations section.

   o  Added host behavior considerations section.

   o  Extended security considerations section.

   o  Added Acknowledgment section, including reference to prior sunset4 draft.

Please review and comment.  We think this version is an improvement over the -00 version.

Thanks,
Bob & Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-ipv4flag-01.txt
> Date: December 12, 2017 at 2:27:05 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-01.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-ipv4flag
> Revision:	01
> Title:		IPv6 Router Advertisement IPv4 Unavailable Flag
> Document date:	2017-12-12
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-01
> 
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate 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: Fred Baker <[email-masked]>
Date: Wed, 13 Dec 2017 16:01:07 -0800

https://tools.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-01.txt

You're correct, it is improved. However, I still think there is a fundamental issue in that the sets of IPv4 routers and IPv6 routers can be completely disjoint, and the IPv6 routers not know about the IPv4 capabilities. That can be viewed several ways - in the security considerations, you note that it is a potential attack vector, for example. Speaking for myself, I would rather have the hosts decide that there is no IPv4 service available from the fact of not having an address and being in a backoff mode in DHCP than from a potentially erroneous assertion in an unrelated protocol.

It seems to me that the issue could be addressed by using an exponential backoff in DHCP (if you don't get an answer, ask again, but wait increasingly long), eventually stopping asking, and waiting for someone to issue an ARP announcement that they are using an address other than 169.254.x.x.

Would it help if I posted a draft about inferring lack of IPv4 services from the lack of IPv4 data?

> On Dec 12, 2017, at 2:33 PM, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Dec 2017 14:18:24 +1300

> Would it help if I posted a draft about inferring lack of IPv4 services from the lack of IPv4 data?

Yes please. The question in my mind about the IPv4 Unavailability flag is
whether the various host heuristics in section 4 are significantly better
than what you are suggesting. In any case, all we are suggesting is
additional "evidence of absence" compared to the simple absence of DHCP
responses.

Also, of course, the goal here is not to exorcise the demon of IPv4.
It's to minimise pointless traffic and remove a potential attack
vector. How can we best achieve that?

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 14 Dec 2017 14:49:24 -0800

Hi,

> On Dec 13, 2017, at 5:18 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>> You're correct, it is improved. However, I still think there is a fundamental issue in that the sets of IPv4 routers and IPv6 routers can be completely disjoint, and the IPv6 routers not know about the IPv4 capabilities. That can be viewed

I don’t have any data, but I suspect that in most cases they are not disjoint.  I think the question is this mechanism useful in the cases where they are not disjoint and/or under unified management.

>> several ways - in the security considerations, you note that it is a potential attack vector, for example. Speaking for myself, I would rather have the hosts decide that there is no IPv4 service available from the fact of not having an address and being in a backoff mode in DHCP than from a potentially erroneous assertion in an unrelated protocol.
>> 

Yes, please do.  I think the challenge ids to have it be reliable in both the case where there isn’t IPv4 and the case where the host is temporarily isolated from the IPv4 router/services.  Also, how to distinguish from a set of hosts trying to find IPv4 services vs. there is IPv4 service.

> vector. How can we best achieve that?

Right, is it better to send a signal to the hosts, or have them all figure it out themselves.

Thanks,
Bob

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Dec 2017 17:36:28 -0600

On Thu, Dec 14, 2017 at 4:49 PM, Bob Hinden <[email-masked]> wrote:

> >> You're correct, it is improved. However, I still think there is a
> fundamental issue in that the sets of IPv4 routers and IPv6 routers can be
> completely disjoint, and the IPv6 routers not know about the IPv4
> capabilities. That can be viewed
>
> I don’t have any data, but I suspect that in most cases they are not
> disjoint.  I think the question is this mechanism useful in the cases where
> they are not disjoint and/or under unified management.
>
> >> several ways - in the security considerations, you note that it is a
> potential attack vector, for example. Speaking for myself, I would rather
> have the hosts decide that there is no IPv4 service available from the fact
> of not having an address and being in a backoff mode in DHCP than from a
> potentially erroneous assertion in an unrelated protocol.
> >>
> >> It seems to me that the issue could be addressed by using an
> exponential backoff in DHCP (if you don't get an answer, ask again, but
> wait increasingly long), eventually stopping asking, and waiting for
> someone to issue an ARP announcement that they are using an address other
> than 169.254.x.x.
> >>
> Yes, please do.  I think the challenge ids to have it be reliable in both
> the case where there isn’t IPv4 and the case where the host is temporarily
> isolated from the IPv4 router/services.  Also, how to distinguish from a
> set of hosts trying to find IPv4 services vs. there is IPv4 service.
>

I agree, at the very least we need to fully consider both options.

> Right, is it better to send a signal to the hosts, or have them all figure

I believe neither will be a universal solution, but I wonder if we can get
close to a universal solution if we do both.

Fundamentally, I believe a host has to determine for itself if IPv4 is
available or not.  But, I see nothing wrong with providing some bread
crumbs to help the host make the correct determination.

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
===============================================