Subject: [Int-area] Re: I-D ACTION:draft-fenner-iana-exp-2780-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2006 13:53:19 +0100

Some personal comments on this.

I'm in favour of making these assignments. I think they will allow
innovation and deflect some of the pressure for assignments for
essentially private use.

I'd actually question whether we shouldn't state explicitly that
it's OK to use these values in production in a private network.
That was why we defined some diffserv space as "experimental/local"
and so far I don't think it's caused any difficulty. Private
use is nicely defined in RFC 2434 (and 2434bis) and mentioned
in RFC 3692.

> Status of this Document
> 
>    This is a strawman to see what the community thinks of allocating
>    experimental numbers as [RFC3692] proposes to other IANA-maintained
>    number spaces.

Presumably, this is the last version that needs to carry this disclaimer.

> 2.4.2.  IPv4 Multicast
> 
>    The globally routable group 224.0.1.20 is set aside for
>    experimentation.  For certain experiments, the administratively
>    scoped multicast groups defined in [RFC2365] may be
>    useful.[[anchor10: Should there be a 'link-local' 224.0.0.x
>    experiment group? --wcf]]

To me it doesn't really seem necessary. Any link-local resource is
safe to use experimentally, subject to local administration.

> 2.5.  IPv4 Option Type field
> 
>    This document assigns a single option number, with all defined values
>    of the "copy" and "class" fields, resulting in four distinct option
>    type codes.

Maybe add "See Section 8." since otherwise the reader may be puzzled about
where the number is. (Same comment for section 3.5.)

> 3.6.3.  IPv6 Neighbor Discovery Option Type
> 
>    This document assigns two IPv6 Neighbor Discovery Option Types, TBD1
>    and TBD2.
> 
> 
> 4.  Fields in the IPv4 ICMP header
> 
>    This document assigns two ICMPv4 type numbers, TBD1 and TBD2.  ICMPv4
>    code values are allocated per-type, so it's not feasible to assign
>    experimental values in this document.

Shouldn't each new TBD get an incremented suffix, TBD3 etc.?

>    [I-D.ietf-ipv6-unique-local-addr]
>               Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
>               Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
>               progress), January 2005.

This is RFC 4193 now.

    Brian

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 12 Jan 2006 08:18:17 -0500

Hello;

> safe to use experimentally, subject to local administration.

I would agree. Note that, per RFC2365, there is all of 239/8  
available for any local experimentation, again
subject to local administration, and I would regard that as a better  
place for it.

Regards
Marshall Eubanks

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Jan 2006 15:04:43 +0000

> it's OK to use these values in production in a private network.

I think that might be dangerous - sooner or later someone is going
to willfully disregard 3692.

There needed to be 3692 warnings in both this draft and right
next to the entries in the IANA registry.

There may be a good case for recommending that firewalls and
NAT default to dumping these packets.

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2006 17:12:04 +0100

> next to the entries in the IANA registry.

But are they any different from the warnings appropriate to "private
use" assignments? A private protocol becomes an experiment if it
gets out onto the Internet. I'm not sure I see a distinction. I'm
all in favour of the warnings.

> NAT default to dumping these packets.

That's fairly much the intention of the Security Considerations,
I think - I'm not sure there is much we can teach firewall and
IDS vendors about failsafe defaults.

     Brian