Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

From: Keith Moore <[email-masked]>
Date: Fri, 19 Aug 2011 16:37:02 -0400

I support publication of some document like this one.  Suggestions for clarification to this document:

1. (section 2 in general) I think it's vague for this document to claim that it "updates" earlier documents as if it's changing the text of those documents.  The reader is left with only a vague impression of what is still in place from those documents and what has changed.

I suggest that the language in this draft be changed to first state each new or revised requirement, and then state how this changes recommendations/requirements stated in earlier documents.

2. section 2, page 4 reads:

   implementation details.  Rather, it is intended to ensure that those
   using RFC1812 as a guideline for IP implementations understand that
   IP nodes SHOULD NOT support IPv4 only, and that they should use the
   other informative references in this document as a companion
   guideline for proper IPv6 implementations.

suggest instead:

   implementation details.  Rather, it is intended to ensure that those
   using RFC1812 as a guideline for IP implementations understand that
   IP nodes SHOULD support IPv6 in addition to any support provided for 
   IPv4, and that they should use the other informative references in 
   this document as a companion guideline for proper IPv6 implementations.
   
reason: to me "SHOULD NOT support IPv4 only" seems potentially confusing.

3.  section 2, page 5 reads:

   New IP implementations MUST support IPv6.

   Current IP implementations SHOULD support IPv6.

In general, it's meaningless to impose a requirement on current implementations of anything.  Also, it's not clear what is meant by "new implementations" - does this mean completely new implementations, or revisions of existing implementations?

Suggest that this be restated.  e.g.  "Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient."

4. also section 2, page 5: 

   IPv6 support MUST be equivalent or better in quality and
   functionality when compared to IPv4 support in an IP
   implementation.

This statement could be taken too broadly, e.g. as applying to service offerings rather than just host and router implementations.  Suggest instead:

   Support for the IPv6 protocol in hosts and routers MUST 
   be equivalent or better in quality and functionality when 
   compared to IPv4 support in the same products.

Even then, this strikes me as problematic.  Should an implementation that cannot provide support for every IPv6 feature (perhaps because of inherent differences between IPv4 and IPv6, or because some feature hasn't yet been updated to support IPv6) be expected to remove features from its IPv4 stack so that its IPv6 stack is "equivalent or better"? 

At the very least, I think the MUST should be a SHOULD.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Aug 2011 11:15:24 +1200

I fully support this document. It could be tuned in the way
Keith suggested, but basically it is a Good Thing.

Regards
   Brian Carpenter

---

From: SM <[email-masked]>
Date: Sat, 20 Aug 2011 11:11:58 -0700

At 11:33 19-08-2011, The IESG wrote:
>The IESG has received a request from the Internet Area Working Group WG
>(intarea) to consider the following document:
>- 'IPv6 Support Required for all IP-capable nodes'
>   <draft-ietf-intarea-ipv6-required-01.txt> as a Proposed Standard
>
>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 2011-09-02. Exceptionally, comments may be

 From Section 1:

   "However, due to the success of the Internet in finding new and
    innovative uses for IP networking, billions of hosts are now
    connected via the Internet and requiring unique addressing."

That sounds like the requirement for unique addressing is a 
problem.  The draft mentions that demand has lead to the exhaustion 
of the IANA global pool of unique IPv4 addresses.  Should the above 
be read as "requiring unique IPv4 addressing"?

   "The exhaustion of IPv4 and the continued growth of the internet
     worldwide has created the driver for widespread IPv6 deployment."

As a nit, that should be "exhaustion of the IANA IPv4 global pool".

   "However, the IPv6 deployment necessary to reduce reliance on IPv4 has
    been hampered by a lack of ubiquitous hardware and software support
    throughout the industry."

Quoting RFC 5218:

   'The lack of a value chain can make it difficult for a new protocol to
    progress from implementation to deployment to use.  While the term
    "chicken-and-egg" problem is sometimes used to describe the lack of a
    value chain, the lack of implementation, deployment, or use is not
    the cause of failure, it is merely a symptom.'

The assertion that the problem is a lack of ubiquitous hardware and 
software support throughout the industry is incorrect.  It is the 
lack of the value chain that has hampered IPv6 deployment.

   'Many vendors, especially in the consumer space have continued to
    view IPv6 support as optional. Even today they are still selling
    "IP capable" or "Internet Capable" devices which are not IPv6-capable,
    which has continued to push out the point at which the natural hardware
    refresh cycle will significantly increase IPv6 support in the average
    home or enterprise network.'

Many vendors in the consumer space such as Internet Service Providers 
still view IPv6 support as optional.  They are still pushing the 
"Internet" as an IPv4 medium only.  Considering that I am living on 
an IPV6 island, let's see whether the following domains would accept 
my messages:

   icann.org
   ietf.org
   itu.int

Let's push this further by sampling domains in recent RFCs:

   cisco.com
   ericsson.com
   alcatel-lucent.com
   nttv6.net
   juniper.net
   nokia.com
   huawei.com
   us.ibm.com
   microsoft.com
   orange-ftgroup.com

For anyone who doesn't want the bother to figure it out, the answer is two.

Even if the average home gets an IPv6-capable device, that would not 
get it any further due to last-mile issues.  The ISP probably forgot 
to include RFC 2460 support as part of its requirements.  Now, you 
can understand why "they" (not referring to any specific group) find 
it difficult to wean off 32-bit integers.

   "For the same reason that the average consumer is not making a
    purchasing decision based on the presence of IPv6 support in
    their Internet-capable devices and services, consumers are
    unlikely to replace their still-functional Internet-capable
    devices simply to add IPv6 support - they don't know or don't
    care about IPv6, they simply want their devices to work as
    advertised."

Consumers are likely to replace their still-functioning 
Internet-capable device if they perceive that it will help them 
fulfill a "want".  Anyway, let's get to the meat of the draft.

 From Section 2:

   'Updates [RFC1812], especially sections 1, 2, and 4 which use the
    generic "IP" synonymously with the more specific "IPv4."  Since
    RFC1812 is an IPv4 router specification, the generic use of IP in
    this standard may cause confusion as IP is redefined to mean IPv4 +
    IPv6.'

The title of RFC 1812 is "Requirements for IP Version 4 
Routers".  The update proposed in this draft causes even more 
confusion as it is unclear what text is being updated in RFC 1812.

   'Updates [RFC1122] to clarify that this document, especially in
    section 3, primarily discusses IPv4 where it uses the more generic
    term "IP" and is no longer a complete definition of "IP" or the
    Internet Protocol suite by itself.'

This second update is again confusing as text does not get updated 
"for example".  As the intended status of this draft is Proposed 
Standard, there is a presumption that if it is going to update STD 3, 
it will do so clearly.

   'Updates [RFC4084] to move "Version Support" from Section 4,
    "Additional Terminology" to Section 2, "General Terminology." This
    is to reflect the idea that version support is now critical to
    defining the types of IP service, especially with respect to Full
    Internet Connectivity."

I don't consider this as a valid reason to update BCP 104.  The 
"document provides a list of terms and definitions that may be 
helpful to providers, consumers, and, potentially, regulators in 
clarifying the type and character of services being offered".  Moving 
version support from Section 4 to Section 2 does not make the 
document more helpful.  I get blank stares when I ask about "IP 
dresses".  I have yet to find out what will happen when I ask about 
"IP sex dresses".

Seriously, BCPs, in general, are about what's happening in the wild 
and not IETF wishful thinking.  If you are going to take a RFC 
written for a wider audience and stick an "Updated by" into it, the 
reader might not see the change.

   "Rather than update the existing IPv4 protocol specification standards
    to include IPv6, IETF has defined a completely separate set of
    standalone documents which cover IPv6."

Was there a reason for that?

   "From a practical perspective, the requirements proposed by this draft
    mean that:

       New IP implementations MUST support IPv6."

draft-ietf-intarea-ipv6-required-01 has an informative reference to 
RFC 2460.  Do I have to understand what IPv6 is about if it is 
required that my new IP implementation supports it?

BTW, this draft has nine pages and four authors.  The 162-page draft 
I read recently has five authors.  "If there is a desire to 
demonstrate how many companies are interested in this spec, a simple 
acknowledgment section can accomplish the same thing".

I do not support the publication of this document as a RFC.  It 
attempts to update old RFCs which are well-written in a confusing 
manner.  The draft comes out as a statement about "IPv6-required" 
instead of a Proposed Standard.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Aug 2011 11:49:42 +1200

Hi Subramanian,

I think most of your comments will be dealt with by
wordsmithing,  but...

On 2011-08-21 06:11, SM wrote:
...
> The title of RFC 1812 is "Requirements for IP Version 4 Routers".  The
> update proposed in this draft causes even more confusion as it is
> unclear what text is being updated in RFC 1812.

It't quite clear to me, but we could spell it out: s/IP/IPv4/.

> This second update is again confusing as text does not get updated "for
> example".  As the intended status of this draft is Proposed Standard,
> there is a presumption that if it is going to update STD 3, it will do
> so clearly.

Ditto.

> "document provides a list of terms and definitions that may be helpful
> to providers, consumers, and, potentially, regulators in clarifying the
> type and character of services being offered".  Moving version support
> from Section 4 to Section 2 does not make the document more helpful.  

Yes it does. It clarifies, for consumer organizations for
example, the IPv6 is not additional technology but is part of
any general IP service.

I
> get blank stares when I ask about "IP dresses".  I have yet to find out
> what will happen when I ask about "IP sex dresses".
> 
> Seriously, BCPs, in general, are about what's happening in the wild and
> not IETF wishful thinking.  

They are about the best practices that the IETF wishes were
being used in the wild.

If you are going to take a RFC written for a
> wider audience and stick an "Updated by" into it, the reader might not
> see the change.

Of course - we have that problem every time we update any RFC.
It is quite orthogonal to the question whether we *should*
update the RFC.

> Was there a reason for that?

Yes. Because IPv4 has no address extensibility, it was
impossible to update it for larger addresses. That has been
known since 1981 or thereabouts.

   Brian

---

From: SM <[email-masked]>
Date: Sun, 21 Aug 2011 00:02:21 -0700

Hi Brian,
>I think most of your comments will be dealt with by

See comments below.

>It't quite clear to me, but we could spell it out: s/IP/IPv4/.

That's clearer.

>example, the IPv6 is not additional technology but is part of

Section 2 of RFC 4084  lists the primary IP service terms:

  (a) Web connectivity

  (b) Client connectivity only, without a public address

  (c) Client only, public address

  (d) Firewalled Internet Connectivity

  (e) Full Internet Connectivity

And with the proposed update:

(f) Version support.

       Does the service include IPv4 support only, both IPv4 and IPv6
       support, or IPv6 support only?

I don't think that it makes sense as it stands.  If you want to 
wordsmith this, you could go with:

  (f) IPv4 Internet Connectivity.

       This service provides the user IPv4 Internet connectivity, with
       one or more static public IPv4 addresses.  Dynamic IPv4 addresses
       that are long-lived enough to make operating servers practical
       without highly dynamic DNS entries are possible, provided that
       they are not characterized as "dynamic" to third parties.

  (g)  IPv6 Internet Connectivity.

       This service provides the user/consumer IPv6 Internet connectivity,
       with at least a /60 IPv6 prefix.  Dynamic IPv6 addressing that are
       long-lived enough to make operating servers practical
       without highly dynamic DNS entries are possible, provided that
       they are not characterized as "dynamic" to third parties.

Note: The above sub-section would need some more work as a host can 
do with one IPv6 address whereas a home user could get an IPv6 
prefix.  I used a /60 prefix.  Some people may view a /56 as more 
appropriate.  The sub-section could be broken into two, one for users 
and the other one for consumers.

  (h)  Full Internet Connectivity.

       This service provides the user with both IPv4 Internet Connectivity
       and IPv6 Internet Connectivity.

>They are about the best practices that the IETF wishes were

Then it should be expected that there will be a wide disconnect 
between what the document says and what is happening in the wild.  In 
essence, if there is no motivation to adhere to some semblance of 
reality, the IETF's wishes will remain best wishes.

>It is quite orthogonal to the question whether we *should*

Most RFCs are not written for a wider audience.

>known since 1981 or thereabouts.

And that is probably why it did not make sense to update the IPv4 
specifications to point to IPv6 specifications.  In my opinion, it 
also does not make sense to do likewise with those old RFCs.  The 
Abstract Section mentions that:

    "this document deprecates the concept that an IP-capable node MAY
     support IPv4 _only_, and redefines an IP-capable node as one which
     supports either IPv6 _only_ or IPv4/IPv6 dual-stack."

IPv6 node requirements are defined in RFC 4294.  It's merely an 
informative reference in draft-ietf-intarea-ipv6-required-01.  The 
discussion about IPV4 address pool exhaustion (Section 1) is a 
distraction from a definition of an IP-capable node.  If the 
intention is to push for IPv6 support in all nodes so that an IP node 
is ubiquitous with IPv4 and IPv6, it would be helpful to have a clear 
and concise document about that.  I do not view concise as saying 
"MUST support IPv6" and be done with it.  The document would state 
which technical specifications an IP-capable mode must support.

Regards,
-sm

1. http://www.6ip.cu/documentos-cuba/R140-08.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Aug 2011 10:59:03 +1200

...
> distraction from a definition of an IP-capable node.  If the intention
> is to push for IPv6 support in all nodes so that an IP node is
> ubiquitous with IPv4 and IPv6, it would be helpful to have a clear and
> concise document about that.  I do not view concise as saying "MUST
> support IPv6" and be done with it.  The document would state which
> technical specifications an IP-capable mode must support.

That is the role of draft-ietf-6man-node-req-bis (which, if
approved, will obsolete RFC 4294). There are practical reasons
why both of these documents are Informational, and thefore would
require special arguments to be cited normatively.

   Brian

---

From: "t.petch" <[email-masked]>
Date: Mon, 22 Aug 2011 09:09:47 +0200

I find this document utterly bizarre and think it would seriously damage the
Internet to publish it.

The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is
fine, the sort of statement that the IAB should make, or have made, as an RFC or
in some other form.

But this I-D claims
" Updates [RFC1122] to clarify that this document, especially in
   section 3, primarily discusses IPv4 where it uses the more generic
   term "IP" and is no longer a complete definition of "IP" or the
   Internet Protocol suite by itself.  "

IPv4 is a phenomenal success, and RFC1122 is a key part of that.  IPv4 was a
confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut
through the cruft and rendered it usable.  IPv6 desparately needs an equivalent
to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is
never going to be it, but claiming that this I-D provides an update to RFC1122,
coupled
with its title, gives the message that there is not going to be such an I-D;
IPv6 will remain a confused jumble (and so is unlikely ever to emulate the
success of IPv4).

Bin it.

Tom Petch

----- Original Message -----

---

From: [email-masked]
Date: Mon, 22 Aug 2011 13:54:47 -0700 (PDT)

> I find this document utterly bizarre and think it would seriously damage the

This seems a little ... extreme. The document appears to me to be Mostly
Harmless, with all that implies.

> to RFC1122,

Complete agreement on this point. Such a document, informed by actual IPv6
deployment experience at some sort of scale, is urgently needed. And this most
certainly is NOT that document. But unless publishing this is seen as meeting
the need for an 1122v6 - and I've seen no indication that's the case - I fail
to see the harm.

OTOH, if this really is seen as being a 1122v6, then I join you in opposing
it's publication.

> as a trawl of the v6ops list archives shows, and clearly this I-D is

Maybe I'm being clueless about this, but I don't see how "IPv6 Support Required
for all IP-capable nodes" gives this impression.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Aug 2011 10:53:55 +1200

+1 to Ned. I can't see why this draft seems to make some people
go defensive - it isn't saying "IPv4 is evil" or anything silly
like that, it's just saying "IPv6 is the future".

RFC1122v6 is another matter entirely. We clearly aren't ready
for it yet, but draft-ietf-6man-node-req-bis is a step on the way.

Regards
   Brian

On 2011-08-23 08:54, [email-masked] wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Peter Koch <[email-masked]>
Date: Tue, 23 Aug 2011 08:32:41 +0200

>              IPv6 Support Required for all IP-capable nodes
>                   draft-ietf-intarea-ipv6-required-01

The document strives to convey the message that "IP" is no longer
equivalent to "IPv4", which is a goal that I'd fully support.
However, while this is a political statement that the IETF really should
make, i have a large amount of scepticism that the document, as
it is written, can successfully convey the message to the desired
target audience.

For one, i share the concerns raised by others that "updating" various
old RFCs is not the right way to go.  First, the documents technically
are not in need of an update (e.g., because RFC 1812 pretty clearly
states that it deals with v4 routers only). Second, changing sentences
or phrases in existing documents, although not without precedent, isn't
best IETF style. This is especially dubious w.r.t. RFC 4084, BCP 104.

Most importantly, though, the updates to existing documents are so
sophisticated and so highly likely to be overread that I'd not see
anybody who managed to remain unaware until today to now follow suit.
It feels a bit like giving purchase departments, or maybe even
legal departments a lever to defeat claims that a product is "IP capable"
when it indeed is IPv4 only.

In that context, these two statements

>       Current IP implementations SHOULD support IPv6.

appear especially interesting. What divides implementations into "new"
and "current" and what's the purpose of stating requirements for
"current" implementations, assuming an intuitive meaning of the word?

I'd agree the IETF (and other I* bodies) have a point in making
strong statements about IPv6 adoption, but the IETF has traditionally
abstained from addressing individual false claims of "RFC compliance".
To that extent i do not see how this would be different for the draft
in Last Call.  For the really agnostic, it also isn't too helpful
since RFCs 1812 and 1122 are of lesser concern.  Documents like RIPE-501,
although not ideal, provide much better guidance.

In summary, if the core message is "IP != IPv4" then i believe the
text isn't crisp enough; if it were bullets for legal/purchase, i do not
see the point.

-Peter

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Aug 2011 15:08:43 +0100

> for it yet, but draft-ietf-6man-node-req-bis is a step on the way.

I agree with Ned and Brian.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Aug 2011 13:31:11 +0900

Before requiring IPv6 support, it is necessary to revise obviously
broken parts of IPv6.

For example, ICMPv6 generated agaist multicast packets should be
forbidden or ICMPv6 implosions will occur. It will let ISPs filter
ICMPv6, including but not limited to, those against multicast,
which means PMTUD won't work.

Another example is lack of guaranteed value for payload size.

RFC791 specifies:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

and DNS just send 512B messages (520B including UDP header,
which should be a mistake but is safe as no one use IPv4
options).

However, there is no such size specified with IPv6, because
arbitrarily lengthy header options may be inserted. Note that
some header options, such as mobility ones, are inserted by
IP layers without application control.

Thus, applications like DNS can not specify like RFC1035:

   Messages carried by UDP are restricted to 512 bytes (not
   counting the IP or UDP headers).

						Masataka Ohta

PS

You have been warned.