Subject: Re: IPv6 MIB revisions: comments solicited

From: Bill Fenner <[email-masked]>
Date: Thu, 12 Apr 2001 08:31:03 -0700

Sorry for not specifying in the original email.  We should have the
discussion on the IPNG list.

  Bill
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mike MacFaden <[email-masked]>
Date: Fri, 20 Apr 2001 17:39:44 -0700

Bill,

Here are 36 items on draft-ops-rfc2011-update-00.txt 

Regards,
Mike
        
1. This MIB module has read-write objects,
   please define the persistence of a set operation for
   ipForward, ipDefaultTTL, etc.
   See section 3.1.12 of draft-ietf-snmpconf-bcp-04.txt

2. There is no support for multi-stack/same Address Family 
   implementations. Please consider support and if 
   not, then please state reasoning in front matter.
   See section 3.1.20 of draft-ietf-snmpconf-bcp-04.txt 

3. I suggest liberal use of REFERENCE clause 
   for objects that represent fields exactly as defined 
   in an underlying protocol specification. 
   For example ipv6DefaultHopLimit
   as specified in 2460 sec 3, 8.2). For a well
   developed example, see RFC 2674.
   http://www.nanog.org/mtg-0102/ppt/mibs/sld010.htm    

4. ipv6Forwarding: The DESCRIPTION is not appropriate.
   An agent caps document would define the implementation
   limitations. 
   The recommendation as to what to return 'wrongValue' is
   protocol specific. A future version of the SNMP 
   may prefer a different way to indicate the lack of
   a capability.
     "Note that for some managed nodes, this object may take on
     only a subset of the values possible.  Accordingly, it is
     appropriate for an agent to return a `wrongValue' response
     if a management station attempts to change this object to an
     inappropriate value."
    
5. "what about SIIT object saying whether an IPv4 address?
   describe SIIT mapped or natively mapped on a dual-stack system?"

   Based on this statement in rfc2765, section 1:
      "Note that SIIT is not likely to be useful later during transition
      when most of the Internet is IPv6 and there are only small islands of
      IPv4 nodes,..."
   I suggest any such objects be placed in a new SIIT MIB module and
   not defined here.   

6. Please define an explicit object(s) to express capability of an
   implementation. See the object dot1dDeviceCapabilities 
   as defined in rfc 2674.
   Section 4 of rfc 2460 provides the list
   of extension headers, it is probably that some implementations
   may not implement all features or if future extensions headers
   are added, it will be useful to identify what a given implementation
   supports. For IPv6, it might includes handling of
   various headers, flow label, traffic class, ..

7. I like the ipv4IfTable as it makes more sense to organize
   some IP attributes by ifIndex. You might also consider the following:
       - directed broadcast (T/F)
       - proxy-arp (T/F)
       - tcp header compression (T/F)
       - broadcast address -->  ipAddressv4BcastAddr
       - arp cache timeout (NUM/UNIT secs)
        
   For an example of existing IPv4 implementation that allows per
   interface configuration, see ip sub-interface CLI command on a
   Cisco IOS(tm).
   
8. General request: Please add *LastChange and *Number objects 
   for all tables to allow mgmt apps to maintain caches.

9. ipv6InterfaceTable -
   ipv6InterfaceEffectiveMtu - like you said, can be easily computed.
   ipv6InterfaceReasmMaxSize - my experience is this is not per interface.
        
   "ipv6InterfaceAdminStatus: does it make sense to enable/disable
   IPv6 on its own on the interface?"

   One will want to enable/disable a given Address Family on a 
   interface shared by multiple address families. 
   I've seen implemented systems where there are entries 
   in the ifTable for IP Interfaces that provide the functionality. 
   I'd prefer a single table to enable/disable an 
   IP Interface(struct ifnet) as opposed to a port. 
    
   See: http://www.nanog.org/mtg-0102/ppt/mibs/sld051.htm
        
   "ipv6InterfaceOperStatus: other than the above, noIfIdentifier(3)
   is this one's only useful state, which can be determined from
   the Address table if DAD failed or there is no v6 address on
   this interface. [not efficiently, though]"
     
   I prefer we have an OperStatus if an admin status is included. 
   It would be useful even in IPv4 to see what else might fail such
   as dhcp assigned addresses or in a particular implementation
   some lack of resources, etc.
        
     ipv6InterfaceIdentifier        Ipv6AddressIfIdentifier, 
     ipv6InterfaceIdentifierLength  INTEGER,
     ipv6InterfacePhysicalAddress   PhysAddress
        
   I suggest the compliance section state it is acceptable 
   that MIN-ACCESS be read only.
   Most interfaces for  will compute these
   and even for interfaces which may not be straight forward
   like serial, the current drafts stil provide a way to
   have an implementation generate acceptable values.

     "When can this be different from the address of the
     interface's protocol sub-layer, and why?""
        
   I am aware of at least one IP router
   that ships with a cache of operator assignable 
   IEEE MAC addresses to provide to user define 
   IP interface.
   All physical ports in the system have one hardwired MAC, hence
   the ifPhysAddr of the port != ipNetToMediaPhysAddress
   of the given IP Address.
        
10. ipIfStatsTable -
   "A row with an ipIfStatsIfIndex value of zero indicates a
    system-wide value; a row with a non-zero ipIfStatsIfIndex"

    Using 0 in an index is not recommended. Please see 
    section 3.1.7 of draft-ietf-snmpconf-bcp-04.txt.

11. ipIfStatsTable counters - 
    Most of these counters are so weakly defined such that 
    two implementations may not count the same thing.
    Please fix these counters so they are derived from 
    the underlying protocol specs. 
    Then use a REFERENCE clause in the MIB module to link
    to the value (See RFC 1493 for example).
    This will help ensure two different implementations have 
    some verifiable consistency for these counters.
    Also, these counters are subject to discontinuity. 

    For all counters, please specify which discontinuity
    object to use. Some background info here:
    http://www.nanog.org/mtg-0102/ppt/mibs/sld030.htm

12. Since ipIfStatsInTooBigErrors is only valid for IPv6,
    please state what to do for IPv4 in compliance stmts
    such that this object may or may not exist.

13. I started to wonder if ipIfStatsTable will need
    two separate counter sets by address family. Then I
    realized it isn't necessary as rfc2011/1213 are not
    going to go disappear from any new implementation
    any time soon.

14. ipIfStatsTable counters - refresh rate
    different implementations often have different 
    refresh rates for snmp counters. 
    It might be useful to have an read-only 
    object to express the implementations
    refersh rate on such counter 
    in milliseconds to minutes. See
    http://www.nanog.org/mtg-0102/ppt/mibs/sld036.htm

15. Internet Address Prefix table -
    I suggest ipAddressPrefixOrigin enum be a TC
    Also suggest "wellknown" be better defined as to what
    document defines the well known addresses (iana?)
        
16. I can't see how ipAddressPrefixTable is useful for IPv4.
    Why can't this jut remaing an ipv6 table with references
    to rfc2461/draft-ietf-ipngwg-site-prefixes-05.txt

          ipAddressPrefixOnLinkFlag
          ipAddressPrefixAutonomousFlag
          ipAddressPrefixAdvPreferredLifetime
          ipAddressPrefixAdvValidLifetime

17. ipAddressIfIndex description should
    just refer to IF-MIB and not rfc2863.

18. ipAddressType, maybe reiterate that broadcast 
    isn't valid option for IPv6 w/reference to 
    draft-ietf-ipngwg-addr-arch-v3-05.txt      
        
19. ipAddressPrefix value "0.0" is good. 
        
20. ipAddressOrigin should be a TC (see item 15) 
    I prefer dhcp (v6 or v6 if need be) over some
    general string such as "assignedByServer" anyone 
    using bootp?
    I don't know what is "random" - 
    how does this differ from manual?
        
21. There should be an object ipAddressOriginCreationTime
    which is the sysUpTime when the assignment 
    was made.
        
22. ipAddressStatus should be a TC if it needs to exist at all.
    I am not sure how useful all these states are and if
    two implementations will even come close in terms
    of using them the same way.
        
    a) If I assign an interface to a port, 
       it goes preferred, then I 
       delete the assignment, the state goes either to 
       deprecated and at some time, the row is aged out 
       or the row simply will fail to exist.
    b) The inaccessible(4) value is unnecessary. It is simple
       to scan the ifTable corresponding to ipAddressIfIndex
       and determine state. 
    c) I doubt invalid(3) would ever be used. 
    d) duplicate() - this is interesting idea, but
       not sure how useful it is and at what time the status
       of this object would transfer out of duplicate state
       once entered.
    e) is tentative only applicable to IPv6?

23. If ipAddressStatus survives the next edit, 
    it needs the equivalent of ifLastChanged.

24. inetNetToMediaTable - 
    might want to reference ARP protocol specifications.
  
25. inetNetToMediaType -
    Adding 'local' value is redundant. It provides 
    no addtional value I can see. 
    'static' works just fine for this case. 

26. "inetNetToMediaState - why no value for incomplete?"
    I agree it would be useful to add text to
    a) describe if these should be in the table 
    b) if so how to represent it (ie use 0 for PhysAddress).
        
      The past implementations I'm familar with
      have not listed unresolved entries.
        
    I think a separate table might exist for these though
    along with some stats/counts/high-watermarks, etc.
    Table description should state what it expects.

27. "inetNetToMediaState - what values for !ipv6?  noNUD(7) or unknown(6)?"

    The description states use unknown(6) which is fine by me.
        
      If Neighbor Unreachability Detection is not in use (e.g. for
      IPv4), this object is always unknown(6) XXX ?noNUD(8)?."

28. ScopeIdentifier - remove reference to rfc2233 in description.
        
29. "Should there be associated objects to provide a scope description,
       similar to ipMRouteScopeNameString?"
         
    I don't think so.
    I can see that it might be useful for diagostics, but I don't
    think the admin overhead of setting it up is reasonable?
    
30. inetIcmpTable - Use of value 0 is not recommended. see 
    item #10 above.

31. The summary counters might not be all that useful in the
    form presented. Especially if the number 
    interfaces are large in a given network element.
    As an alternative to a summary, maybe provide 
    a "top N" style view of icmp errors by interface
    to answer the question, which interfaces have the
    most errors?

32. inetIcmpTable should reference underlying spec for counters.
    See item #11 above.

33. inetIcmpMsgTable - same indexing problems as #30
    inetIcmpMsgEntry, if you remove the summary indexing
    the table's values make implementation more likely
    to be correct. I don't see what the summary really
    buys anyway when getting such detailed information.
    I think this table should be optional on a per
    interface basis too.

34. inetIcmpMsgTable - special value 256.
    A different implementation would simply provide the
    counts in some scalars of the "others" category. Current
    model seems needlessly convoluted.
        
35. inetIcmpMsgTable - it may be that operators only want
    to see certain icmp messages and not all?

36. inetIcmpMsgType - should  be a TC and include a reference
    to underlying spec.
    Other MIB modules should  able to use the same definition.

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 20 Apr 2001 18:42:37 -0700

>    how does this differ from manual?

Random is very different from manual, and means the
system randomly generated the host id.
Two examples of addresses that use random today:
* RFC 3041 privacy addresses
* draft-ietf-zeroconf-ipv4-linklocal-02.txt autonet addresses

>     e) is tentative only applicable to IPv6?

No.  Most stacks do gratuitous ARP for duplicate
Address detection when adding a new IPv4 address.
Hence, the same tentative state exists.

-Dave