Subject: Re: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 2 Oct 2017 02:43:40 -0500

Just to say this at Last Call time, so it's not an IESG Evaluation late
surprise ...

On Sep 29, 2017 08:06, "Denis Ovsienko" <[email-masked]> wrote:

---- On Thu, 28 Sep 2017 14:26:22 +0100 The IESG  wrote ----
>
>The IESG has received a request from the Sunsetting IPv4 WG (sunset4) to
>consider the following document: - 'IETF: End Work on IPv4'
> <draft-ietf-sunset4-ipv6-ietf-01.txt> as Proposed Standard

Hello all.

In addition to what has been said already about the present revision of the
document, let me make a suggestion for its next revision if the working
group decides to work on it.

What such a document could propose is that all new I-Ds have to include an
"IPv4 Considerations" section, which either states that the document has
absolutely nothing to do with IPv4 (and in that case the section is removed
before the publication) or actually makes relevant considerations along a
set of guidelines (like RFC 5226 explains how to make IANA considerations).
This will help both authors and readers spend sufficient time thinking
about how the document will work in IPv4-only, IPv6-only or double-stack
environments, so that they can identify more real issues before the
publication or the implementation.

To keep those guidelines right-sized, the document could make IPv4
considerations for recent 10-15 protocols/documents to show how it works
and what problems it would help to avoid.

If we did this, I wonder if the apparently-BCP-to-be might establish a
default of IPv6-only, so that drafts that aren't IPv6-only are the only
ones affected. In a perfect world, we would see more specifications that
aren't explicitly IPv4-only or explicitly dual-stack, so only the drafts
that are going down the exception path would be affected.

We should also remember that the community has been more resistant to
adding mandatory sections to all RFCs in recent years, so, there's that.

Thanks,

Spencer, speaking as an individual who's watching this discussion pretty
closely ...

--

    Denis Ovsienko

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Oct 2017 08:54:42 +0100

> adding mandatory sections to all RFCs in recent years, so, there's that.

I don't think an IPv4 Considerations section is a good idea. Unlike
security considerations, it should be almost always empty and so it
would just be more bureaucratic boilerplate, and hence a bad idea.

I also had a read of the document itself and agree with the comments
that the tone is wrong. To add one more example, the opening sentence
of section 1 says "The IETF has developed IPv6 to replace IPv4." I
agree that is a true statement. However it is also pretty misleading
as I believe many IETF participants do not now believe that IPv6 will
replace all IPv4 traffic in say the next two decades. I do however
agree that we ought stop adding features to IPv4 that don't work for
IPv6, but the text of the statement needs significant work still.

S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 2 Oct 2017 10:09:49 +0200

Hmm.  Begins to seem like a good fit for the shepherd write-up, though...

Eliot

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 2 Oct 2017 03:16:39 -0500

On Oct 2, 2017 03:09, "Eliot Lear" <[email-masked]> wrote:

And requires much less BCP twiddling ...

Eliot

> would just be more bureaucratic boilerplate, and hence a bad idea.

I may not have said this clearly, but Stephen said what I'm trying to say.

Not mandatory for all RFCs, only the ones that need it.

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Oct 2017 09:17:21 +0100

On 02/10/17 09:09, Eliot Lear wrote:
> Hmm.Â  Begins to seem like a good fit for the shepherd write-up, though...

Maybe. I'd be fine if the IESG had a policy that anything
that is IPv4-only has to be explicitly justified, either via
text in the relevant draft (or charter), or as part of a
shepherd write up. (Note though, that such a policy could,
and I hope would, be a fine precedent if someone proposed a
policy relating to privacy invasive technologies also requiring
explicit justification - that is a reason I'd support such a
policy for IPv4-only text but that might not work for other
folks.)

S.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 2 Oct 2017 09:23:37 +0100

On 02/10/2017 08:54, Stephen Farrell wrote:
> I do however
> IPv6,

Something that has been nagging me for a while is that the underpin of 
this statement,
is the assumption that IPv4 and IPv6 are equivalent and work the same 
way. However,
they do not work the same way. For example, IPv4 uses ARP and permits 
in-network
fragmentation. So statements such as the above would mean that 
legitimate maintenance
might be precluded.

Rather than tie millstones to IPv4, wouldn't it be better to demonstrate 
the compelling
advantage of IPv6?

- Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Oct 2017 09:29:10 +0100

Hiya,

On 02/10/17 09:23, Stewart Bryant wrote:
> way. 

I didn't make that assumption.

> However,

I don't think legitimate maintenance adds features, at least
not in the sense I meant. I definitely would not want to see
legitimate maintenance precluded.

> Rather than tie millstones to IPv4, wouldn't it be better to demonstrate

That's easy - the existence of available addresses is compelling
advantage enough:-)

In any case, I think this exchange illustrates the need for more
subtlety in any new policy statement on this topic.

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Mon, 02 Oct 2017 17:42:37 +0900

>> Rather than tie millstones to IPv4, wouldn't it be better to
>> demonstrate the compelling advantage of IPv6?
> 

yes, it has been compelling cgns and nat44444 all the hell over the
place.  major win!

i wonder what we could do about that.  maybe feature parity, such as
dhcp options, classless, ...  the list goes on, and much blood has been
shed.  but we know so much better.  which is why after a quarter of a
century we have finally just passed 10% v6 on the backbone.

multicast, dnssec, ipsec, ipv6, ...  we are not good at making these
things operationally deployable.

now we will try to outlaw work on ipv4.  like that's gonna work.  but at
least it will push internet operations further out of the ietf.

randy

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 2 Oct 2017 10:34:52 +0100

> That's easy - the existence of available addresses is compelling

As a measure of it's importance to the UK national economy I looked up 
Broadband and IPv6
in Hansard (proceedings of London parliament).

Broadband is a proxy for Internet speed and is mentioned in 124 debate 
titles,
has 4027 spoken references, is in 47 written statements, and is the 
subject of
one petition.

IPv6 is in four written statements, and that is it.

> subtlety in any new policy statement on this topic.

On that I agree.

Stewart

---

From: Jacques Latour <[email-masked]>
Date: Mon, 2 Oct 2017 15:16:32 +0000

I think we need to be very specific to mention where the focus is applied, either in on the global Internet or on the Network {internal, home, corporate}.

Saying we're shutting down IPv4 scares a lot of people but that's not in scope because on the Network (internally) come to mind right away. The focus is on the Internet.

Abstract
 
  The IETF has stopped working on IPv4 protocol only solutions that are specific to global Internet.
  The IETF has stopped working on IPv4 protocol solutions except where needed to mitigate documented security issues.
  The IETF has not stopped working on IPv4 protocol solutions to facilitate the transition to IPv6, or to enable IPv4 decommissioning on the global Internet.
  The IETF has no 'plans' to decommission the IPv4 protocol on the Network {internal, home, corporate}.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Oct 2017 08:26:24 +1300

On 02/10/2017 21:42, Randy Bush wrote:
...
> yes, it has been compelling cgns and nat44444 all the hell over the

In a way I regret not having completely blocked deployment of the http
nonsense back in 1993, when I ran the team that ran the network that
Tim Berners-Lee first polluted with this web stuff. But since I
didn't do that, just as Tim's managers didn't stop him wasting time
on it instead of doing his day job, the massive growth of the IPv4
network (before IPv6 was ready) became inevitable, so NAT44 and
NAT444 became inevitable, so CGNs and NAT64 became inevitable, so
here we are.

> dhcp options, classless, ...  the list goes on, 

Well, we have BCP198 which says clearly enough that the "length of an
IPv6 prefix may be any number from zero to 128" so (despite being
an author of draft-bourbaki-6man-classless-ipv6) I think we have that
one basically right. I'm aware of one DHCPv6 option that is really
lacking (default router) and despite the polemics it baffles me that
we haven't fixed that one.

Apart from that, what else is on the list? That's a serious question,
and a draft that identifies all such items would be a very useful
thing to have. We should focus on sunrise6 rather than sunset4.

    Brian

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 02 Oct 2017 12:32:26 -0700

On 2 Oct 2017, at 12:26, Brian E Carpenter wrote:

> We should focus on sunrise6 rather than sunset4.

Yes, that. However, we have to focus a bit on sunsetv4 now because of 
the IETF Last Call.

--Paul Hoffman

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 2 Oct 2017 21:22:42 +0100

> Yes, that. However, we have to focus a bit on sunsetv4 now because of 

Well maybe the IESG will read this thread and conclude that the right 
approach it to shutdown sunset4, and charter sunrise6, in which case 
this document will have served a useful purpose without it being published.

- Stewart

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Oct 2017 07:29:00 +0900

> this document will have served a useful purpose without it being

the problem is we have ipv6 ivory tower defense, not ipv6 speedbump
removal.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Oct 2017 10:13:55 -0400

> NAT444 became inevitable, so CGNs and NAT64 became inevitable, so

​Since I spent much of the morning looking at material posted by Internet
Research Agency bots ​peddling false stories in the hope of exploiting the
Vegas shooting, I am rather short on tolerating sarcasm right now.

But for the Web, OSI might well have won. When the killer apps of the
Internet were email and file transfer, interconnection between networks
could be achieved as well through gateways as by establishing a consistent
namespace. The Web ended the network wars because URLs didn't work across
network namespaces. So even though you could run HTTP over DECNET phase IV,
there was no point in doing that as all the content was on the Internet.

As for carrier grade NAT being inevitable, it took a very long time for
IETF to accept that fact. People who suggested that the IETF had to work
out how to live with NAT and make it part of the solution were bullied and
isolated. And you were chair while much of the unpleasantness was going on.

The only way to effect any technology change is to make it as seamless and
transparent as possible. That used to be understood, that is why flag days
were considered to be a bad thing.

The strategy adopted instead was to reserve new features for the new
protocol. With the result that new features were also delayed or botched.
It is a long time since I used an IPSEC VPN because they still didn't work
reliably through NAT last time I bothered to try while SSH works pretty
much flawlessly.

If you want IPv6 to work, how about considering doing it my way, just the
once? Not doing it mind, just considering the alternative approach without
driving out the heretics.

It really is quite simple in my view. If you want IPv6 to become
unbiquitous, you need to provide people with a new internet API that
isolates the application from ALL of the IPv4/IPv6/NAT issues. And thanks
to Stuart Cheshire and co, 90% of the work is already done.

At the moment, the network API is in effect:

Address = nslookup_its_an_ipv4_address_right ("example.com")
Socket = get_socket_ipv4 (Address, 80)

(for the other Internet protocol, replace port 80 with 443).

The problem here is that the application programmer is asked to implement
whatever the IPv6 transition strategy is this week. And frankly, why would
any of my engineers bother when IPv4 is guaranteed to work and they have
plenty of other features that are higher in priority.

If you want transition to work, then you need to give the application
programmer a black box that they can plug into their code and just works
without them having to think about it. i.e.

Client = GetOutbound ("example.com", "_http._tcp")
Service= GetInbound ("example.com", "_http._tcp")

or for legacy

Client = GetOutbound ("example.com", 80)
Service= GetInbound ("example.com", 80)

A call to any of those should do all the work for the programmer including:

* Configure NAT (if required) - see TURN/STUN rfc5766
* Resolve the DNS name
* Decide on the session protocol TCP or QUIC
* Decide whether to use a transport layer security (e.g. TLS)
* Validate any cert chain presented

As I said earlier, we already have a spec that almost completely constrains
the space, its RFC6763. I would like to see the space constrained further
and establish standard tags for service properties so that a service can
offer QUIC or mandate use of TLS in a consistent way.

We have all the parts, what has held us back is a series of niche interest
groups who are so obsessed with achieving their own technology transition
that they are oblivious to the fact that they are sabotaging the mission of
the IETF as a whole:

* The IPv6 purists who insisted on sabotaging protocols to prevent use of
NAT

* The DNS purists who insist that the answer to every DNS issue is a new
DNS resource record.

IP and DNS are just plumbing. They matter but nobody ever bought a house
because they were impressed by how beautiful the pipework was. The only
time it enters into the picture is when it isn't working.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Oct 2017 08:23:08 +1300

On 04/10/2017 03:13, Phillip Hallam-Baker wrote:
...> It really is quite simple in my view. If you want IPv6 to become
> to Stuart Cheshire and co, 90% of the work is already done.

I'm not being in the least sarcastic when I say that the other 10% of
the work will take 90% of the time. For more, see my rant in CCR:
https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Oct 2017 15:52:04 -0400

> https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf

​Make that 'decisions are already taken'.

Given that to be viable a scheme has to work with the Apple, Google and
Microsoft platforms and given that further there are precisely zero other
platforms whose support is essential, it follows that any decision that
attempts to rewrite the existing facts on the ground as agreed with at
least one of the parties without good reason is due to fail.​

​90% of the problem is bike shedding anyway. The fact that there is a bike
shed already built and painted means that as far as I am concerned, folk
need to have a very good reason to change the colour.

But that isn't how these discussions go. On numerous occasions, I have
experienced conversations of the form:

Me: I propose we do A because of reasons X, Y and Z.

Other: I disagree, I don't care about reasons X, Y or Z and as far as I am
concerned, B is just as good and ​since I don't care we are going to do it
my way.

And no, I am absolutely not exaggerating. When someone wants to insist on a
particular outcome but does not want to justify it, agenda denial, ruling
the requirements out of scope is the most effective strategy.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Oct 2017 22:22:05 +0200

APIs suffer the neverending debate of "not an IETF job, go to POSIX".
IMHO, IETF should define APIs, eg: let TAPS really do the work thats
now declared out of scope. And then go to POSIX with the results.

APIs are also not the complete answer.
OS independent, readily available and easily adopted network SDKs are the answer. 
Upgradeable independent of app and OS. The only mayor instance of this
are browsers and then look at how slow web sockets are evolving. And
the issue really are the billions of embedded devices / apps where
browsers don't play.

And don't get me started on DNS-SD. Ever tried to use embedded home market equipment like
printers remotely when both client and server use mDNS ? Or trying to figure out
how to set up any form of DNS-SD across VPNs ? But sure, yes, lets first make sure
there is absolutely no way to permit configuration of IP addresses or 
even DNS names so you surely can't get the service to work without configuring
some klunky CLI mDNS proxy from some 10 year old README file.

The road to hell is paved with good intentions. 

Toerless

On Tue, Oct 03, 2017 at 10:13:55AM -0400, Phillip Hallam-Baker wrote:
> ???Since I spent much of the morning looking at material posted by Internet
> Research Agency bots ???peddling false stories in the hope of exploiting the

-- 
---
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Oct 2017 16:23:41 -0400

> some klunky CLI mDNS proxy from some 10 year old README file.

Huh?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Oct 2017 17:04:42 -0400

> now declared out of scope. And then go to POSIX with the results.

​+1

POSIX is a non entity as far as platforms are concerned for a start. If you
want to affect the world then persuade Microsoft, Apple and Google to do
the right thing it will happen. Waiting on an external party that does not
influence the platforms of consequence is doomed to fail.

​If IETF had no influence at all in any of those organizations, we would be
in trouble but the exact opposite is the case. They are all represented in
IETF and the people representing them (mostly) want to do the right thing.​

> the issue really are the billions of embedded devices / apps where

​It is not the API itself so much as the abstract API that is the issue.
What we need to do is to work out which interests we see as being things we
want the application programmer to care about and which things we want them
to NOT care about.

​

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Oct 2017 23:20:05 +0200

On Tue, Oct 03, 2017 at 05:04:42PM -0400, Phillip Hallam-Baker wrote:
> ???It is not the API itself so much as the abstract API that is the issue.

The abstract vs. concrete API distinction is well understood since IMHO more
than 10 years now. What is not understood IMHO is that any protocol stacks
have to be designed so that the folks interested in the functionality can
be the ones implementing them. That aspect is still mostly ignored.

OSs will implement some protocols quicky, and some slow or never. If you can
already see that problem upfront you simply need to define your protocol
accordingly. Eg: on top of UDP so it can be implemented by apps/middleware
developers. And i don't want to have some egytian pyramid architects come
with thousand year old statements that that is not architecturally clean.

Cheers
    Toerless

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:38:45 -0700

On 9/29/2017 6:48 PM, Brian E Carpenter wrote:
> First of all, I agree with those who have said this should be
> a BCP, if published. BCPs are the way we publish IETF process
> rules.
A BCP with the right tone and focus might be useful.

> Secondly, I think many of the comments about the tone and slant
> are correct. What we want to stop is work on solutions that
> are *specific* to IPv4, and to chase down and elminate any
> cases where successful IPv6 operation depends on the presence
> of IPv4.

I disagree.

We need to consider IPv4 work as "maintenance mode", which can easily
include solo IPv4 adjustments and/or include IPv4 support in new
protocols that also support IPv6. Neither necessarily need involve
transition or deprecation.

"no new work" or "no IPv4-specific work" both assume that IPv6 is a
superset of IPv4, which it is not. We're still wrangling with aspects of
IPv6 that actually are evolving back into IPv4-like approaches, e.g.,
limits to the length of the header chain and problems supporting
fragment traversal of routers.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:45:18 -0700

> APIs suffer the neverending debate of "not an IETF job, go to POSIX".

A protocol without an API is dead code.

> IMHO, IETF should define APIs, 

We already have - see TCP and UDP, for example.

> eg: let TAPS really do the work thats
There are differences between the API defined in a protocol and the way
it is implemented in an OS. Both IETF (protocol) and POSIX (OS) have a
role in developing aspects of that interface, but IMO it cannot be the
"turf" of just one of those organizations.

Joe

---

From: [email-masked]
Date: Wed, 4 Oct 2017 12:48:50 +0000 (UTC)

some of us think that security considerations should be almost always empty and is just more bureaucratic boilerplate.
rather like IANA considerations.

Lloyd [email-masked]

On Monday, October 2, 2017, 6:54 pm, Stephen Farrell <[email-masked]> wrote:

S.

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:54:59 -0700

On 10/4/2017 5:48 AM, [email-masked] wrote:
> some of us think that security considerations should be almost always
> empty and is just more bureaucratic boilerplate.
+1

> rather like IANA considerations.

IMO, IANA considerations are quite different; they're not for political
reasons. They help IANA do their job and encourage protocol docs to have
all of the assigned numbers/names info in one place.

Joe

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 4 Oct 2017 20:46:55 +0400

On Thu, Sep 28, 2017 at 6:27 PM, Ted Lemon <[email-masked]> wrote:
> On Sep 28, 2017, at 9:48 AM, Andrew G. Malis <[email-masked]> wrote:
>
> While I sympathize with the intent of this draft, I don’t understand why
> it’s being proposed as a standards track document. It doesn’t define any new
> protocols, nor does it contain any BCP 14 language. Rather, it’s a statement
> of policy for the IETF. I would suggest that it be published as an
> Informational RFC rather than standards track.
>
>
> Informational documents aren't consensus documents.
>
[speaking from an emerging country: Mauritius]

Last time I spoke to local ISPs about v6, they are bay

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 4 Oct 2017 20:51:08 +0400

> Last time I spoke to local ISPs about v6, they are bay

Sorry for the previous mail which is incomplete.

Last time I spoke to local ISPs about v6 for home users, they told me
that they were focused on getting more ipv4 addresses for their
growing backbone needs. This is probably (and sadly) the case of a lot
of ISPs in emerging countries. They are building voip services on top
of ipv4 right now ...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Oct 2017 11:18:02 +1300

> transition or deprecation.

I'm not sure that we disagree modulo wordsmithing. Saying that IPv4
is in maintenance mode is fine. Security and bug fixes are clearly
maintenance.
 
> superset of IPv4, which it is not.

I don't see that assumption either stated or implied. If there are
features missing in IPv6, that's a completely separate topic.

> We're still wrangling with aspects of

I don't see what that has to do with the draft under discussion.

Regards
   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Oct 2017 05:30:14 -0700

> features missing in IPv6, that's a completely separate topic.
I was arguing against new wording that might use the quotes above. IMO,
the current doc is even more restrictive.

> I don't see what that has to do with the draft under discussion.

It was intended as an example of how IPv6 is not a superset of IPv4.

Joe

---

From: S Moonesamy <[email-masked]>
Date: Sun, 08 Oct 2017 08:43:11 -0700

Hello,

I'll disclose that there is a potential conflict of interest and I am 
involved in a RIR [1].

At 06:26 AM 28-09-2017, The IESG wrote:
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2017-10-12. Exceptionally, comments may be

I read this short draft and the document shepherd write-up.  The 
explanation about why the document should be published as a "Proposed 
Standard" is that "it creates key implications on all future 
standards track documents".  Is that what the "Proposed Standard" 
label is about?

There is the following in Section 1: "Until the time when IPv4 is no 
longer inwide use and/or declared historic ..."  It is unrealistic to 
envision a near future where the IETF would "declare" IPv4 as "Historic".

I'll commend the author for not overloading the "must" in this 
draft.  Is this document about the IETF not doing any more work on 
IPv4-related technologies unless there is a security issue to fix and 
there is consensus [2] to do that?

Regards,
S. Moonesamy

1. Please do not read the disclosure as a statement from the RIR.  My 
interest predates the RIR involvement.
2. Please see Section 2 of the draft.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Oct 2017 05:05:32 +0200

- I think the draft needs an introduction to explain some details of the
abstract or the approach used to transit from IPv4 only protocol to IPv6
only protocol.

-  The draft has very good statements which can be done with numbering and
in sequence or in a way to know the level of importance.

- The big statement I think is: The IETF has developed IPv6 to replace IPv4.
Could we rephrase/add: The IETF has developed IPv6 protocols to replace
IPv4 protocols.

- The draft needs some references (normative and informative) for such
approach/direction, because it is important to the Internet Future, or to
All protocols future.

-  There is a contradiction which is:

[AB] in Abstract say:

The IETF will stop working on IPv4, except where needed to mitigate

documented security issues, to facilitate the transition to IPv6, or

to enable IPv4 decommissioning.

[AB]  in statement section :

Some changes may be necessary in IPv4 protocols to

facilitate decommissioning IPv4 in a way that does not create

unacceptable impact to applications or users.

[AB] Stop working on IPv4 is to facilitate IPv4 decommissioning but how can
changing protocols done without working on it some how?

[AB] suggest delete from the abstract: or to enable IPv4 decommissioning.

[AB] Usually the people may stick to old systems for long time, and maybe
old things can become with high value in future (like old cars). The draft
may need to convince users that IETF is not going in the direction of
business (as stopping working on IPv4) against IPv4 system holders. I
suggest referring to an informational document in the proposed introduction
section.

[AB] suggest to add to the abstract the main statement:

The IETF has developed IPv6 to replace IPv4.

New IETF work must function completely on IPv6-only nodes and

networks.

Best

AB

On Thu, Sep 28, 2017 at 3:26 PM, The IESG <[email-masked]> wrote:

> sent to [email-masked] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The IETF will stop working on IPv4, except where needed to mitigate
>    documented security issues, to facilitate the transition to IPv6, or
>    to enable IPv4 decommissioning.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     draft-george-ipv6-support: IPv6 Support Within IETF work (None - )
>
>
>
>

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 16 Oct 2017 10:22:18 -0700

> some klunky CLI mDNS proxy from some 10 year old README file.

Can you elaborate what you’re talking about there?

Every time someone at an IETF meeting taps the AirPrint button and prints on the Terminal Room printer, they’re accessing a printer remotely (i.e., from a different subnet/link, outside the Terminal Room) using unicast DNS-SD. And yes, it works over VPN too.

What are you talking about?

Stuart Cheshire