Subject: Comments on draft-bchv-rfc6890bis-00.txt

From: Kerry Lynn <[email-masked]>
Date: Mon, 18 Jul 2016 17:54:59 -0400

Hi Brian,

I think there may be a problem with the general approach taken by this
draft.

I certainly don't have the full context, but it seems that before RFC 6890
there were separate RFCs to describe IPv4 and IPv6 Special-Purpose
Address Registries.  RFC 6890 obsoleted RFCs 4773, 5156, 5735, and
5736 and apparently attempted to define a set of common predicates that
would apply to both address families.

I've not been able to find archived versions of the pre-RFC 6890 registries,
but many of the predicates in the current python ipaddress library, which
claim to conform to the IPv4 and IPv6 Special-Purpose Registries, contain
terms that no longer appear (e.g. is_private, is_link_local, etc).  See
https://docs.python.org/3/library/ipaddress.html.

If we change "Global" to "Globally Routable" in the IPv6 registry
http://www.iana.org/assignments/iana-ipv6-special-registry
without also doing so in the IPv4 registry
http://www.iana.org/assignments/iana-ipv4-special-registry
then we will once again have divergent terminology and I'm not sure that
is what's intended.

Kerry Lynn

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 17:49:57 +1200

> https://docs.python.org/3/library/ipaddress.html.

To be specific, the one that *this* Brian tripped over was is_global,
which surprised me by returning False for ULAs, which are clearly defined
as having global unicast scope. is_link_local is beyond dispute I think.
is_private is an interesting one - I assumed the Python module author had
invented it.

Python returns is_private = False for 100.64.0.0. I think that's a bug.

(The attached Python3 script may amuse you.)

> then we will once again have divergent terminology and I'm not sure that

'Global' is an undefined property for IPv4 in the Python library. But then,
scope has never been formalised for IPv4 unicast.

   Brian C

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 02:20:45 -0400

On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter <
[email-masked]> wrote:

> I'm not sure it was very clear that I was trying to make three points:

1. The Python library you're using is currently flawed, in that it claims
    consistency with the IPv4 and IPv6 Special-Purpose Address Registries
    but uses obsolete terminology.

2. The "fix" for these registries should probably come in the form of an
    update so that it leaves in place the unifying language intended by
    RFC 6890.  (As a practical matter, I think obsoleting RFC 6890 may
    leave the RFCs it obsoletes in some nether state.)

3. Whatever term is chosen to replace "Global" should apply equally to
    IPv4 unicast (my preference being "Public").

Regards, Kerry

   Brian C

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Jul 2016 03:59:31 -0400

Hi Kerry,

>>> then we will once again have divergent terminology and I'm not sure that

I have not made any changes to the IPv4 registry based on the proposed
changes. *If* someone thinks a specific change is applicable/necessary,
we should consider it. Keep in mind that this document is larger in
scope than just 6man though.

>     but uses obsolete terminology.

Agreed, but I think some of the issue may be the way 6890 defined things
WRT "global".

>     leave the RFCs it obsoletes in some nether state.)

This draft wholly replaces 6890 with just the primary change of "global"
to "globally reachable". The meta-data will allow the relationships
between RFCs to remain. So, I don't see any issue with the state of
obsoleted RFCs.

>     IPv4 unicast (my preference being "Public").

I am not sure how using "public" changes the issue, but we can discuss
that during the f2f session.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 20:00:02 +1200

Kerry,
>     but uses obsolete terminology.

After the dust has settled we can track down the author of that module
to see what can be done without breaking running code.

>     leave the RFCs it obsoletes in some nether state.)

I think that is the intention (and the side effects on older RFCs
need to be checked).

>     IPv4 unicast (my preference being "Public").

Well, as I said, the notion of unicast scope was never developed for
IPv4. I would also prefer it if the "Global-bis" property was also
defined for IPv4, but that isn't a decision for 6man.

As for "Public" that isn't quite the same semantics as "Globally Routeable"
which is really the implication of "Not (Link-Local or ULA)" in IPv6
or "Not (Link-Local or RFC1918 or RFC6598)" in IPv4.

There's no very obviously correct answer for all this. I think
draft-bchv-rfc6890bis-00 is a reasonable compromise.

Rgds
   Brian C

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 05:09:18 -0400

On Tue, Jul 19, 2016 at 3:59 AM, Brian Haberman <[email-masked]>
wrote:

> But RFC 6890 apparently *did* make changes to the IPv4 registry, so if
we obsolete RFC 6890 do those changes remain in effect?

> I haven't been able to locate a copy of the IPv4 registry as it existed
before
being restructured, but I infer that it used predictates like "private" and
"link
local" which were made obsolete by RFC 6890.

> See above.

> I suspect that when the IPv4 registry was restructured, private==false
became global==true.

Regards, Kerry

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Jul 2016 05:15:32 -0400

Hi Kerry,

> we obsolete RFC 6890 do those changes remain in effect?

Yes. All the registry changes made in 6890 are carried over in this
draft modulo the changes I mentioned to the ULA entry and the TEREDO
entry (to address a filed erratum).

> local" which were made obsolete by RFC 6890.

I am not sure of that, but I can ask a few of the co-authors since they
work for IANA.

>> I suspect that when the IPv4 registry was restructured, private==false

No. For example, the 10/8 entry has Global = False.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Jul 2016 05:32:39 -0400

> I am not sure of that, but I can ask a few of the co-authors since they

http://web.archive.org/web/20070630230311/http://www.iana.org/assignments/iana-ipv6-special-registry

https://web.archive.org/web/20120524215600/http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml

Brian

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 05:48:04 -0400

> On 7/19/16 5:09 AM, Kerry Lynn wrote:
<snip>

> entry (to address a filed erratum).

Mea culpa.  I somehow missed that ALL the tables are included in the bis :-/

Regards, Kerry

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Jul 2016 05:50:16 -0400

On Tue, Jul 19, 2016 at 5:32 AM, Brian Haberman <[email-masked]>
wrote:

> Thanks.  No mention of "private", "link local", etc.