This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Net-SNMP does not support creation of IPv6 addresses, only IPv4 ones. I am not sure it is even possible to create an generic IPv6 address (Net-SNMP uses ioctl() for the IPv4). And if it is, it's quite lot of code on Net-SNMP side to add the missing functionality.

This feature request has been proposed after Feature Freeze and we
are unable to resolve it in time for the current Red Hat Enterprise
Linux release. It has been denied for the current release and
proposed for the next Red Hat Enterprise Linux release.

Looking at the kernel ioctls, it looks like it is possible to add ipv6 address. The kernel requires not only interface index and the IP address (both is known to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set using simple snmpset and Net-SNMP does not have any clue what is the desired prefix length. Can Net-SNMP assume that it is always 128?

(In reply to comment #3)
> Net-SNMP does not support creation of IPv6 addresses, only IPv4 ones. I am not
> sure it is even possible to create an generic IPv6 address (Net-SNMP uses
> ioctl() for the IPv4). And if it is, it's quite lot of code on Net-SNMP side to
> add the missing functionality.    

Hi,Jan

Could you tell me the correct command to create ipv4 address? I have tried using the following command to create one row 
"snmpset -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10.1.4.10.0.0.3 i 5 "

But it failed with the following error:
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressRowStatus.ipv4."10.0.0.3"

I have got ipAddressRowStatus via command
"snmpwalk -v 2c -c IPv6ReadyLogo  localhost 1.3.6.1.2.1.4.34.1.10 -Ob"

The result is as follows:
IP-MIB::ipAddressRowStatus.1.4.10.66.92.174 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.1.4.10.66.93.255 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.1.4.127.0.0.1 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.63.254.5.1.255.255.1.0.2.37.100.255.254.166.254.163 = INTEGER: active(1)
IP-MIB::ipAddressRowStatus.2.16.254.128.0.0.0.0.0.0.2.37.100.255.254.166.254.163 = INTEGER: active(1)

 It seems that the oid doesn't contain ifindex.

(In reply to comment #5)
> Looking at the kernel ioctls, it looks like it is possible to add ipv6 address.
> The kernel requires not only interface index and the IP address (both is known
> to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set
> using simple snmpset and Net-SNMP does not have any clue what is the desired
> prefix length. Can Net-SNMP assume that it is always 128?    

Hi,Jan 

 If we have to set the prefix length to a fixed value,as many test cases in TAHI show,64 may be a more common prefix length.But I think it's not the point to check.

Thanks .

xiaoli

It's not so easy to create a row - you have to fill all required columns. Following command creates new interface, but due to bug in snmpd (see bug #616764), it returns error.

$ snmpset  localhost IP-MIB::ipAddressRowStatus.ipv4.4.10.34.25.162  integer 
createAndGo IP-MIB::ipAddressIfIndex.ipv4.4.10.34.25.162 i 1
IP-MIB::ipAddressStatus.ipv4.4.10.34.25.162 i 1
IP-MIB::ipAddressStorageType.ipv4.4.10.34.25.162 i 2

Error in packet.
Reason: (genError) A general failure occured
Failed object: IP-MIB::ipAddressRowStatus.ipv4."10.34.25.162"

But as I wrote, the interface *is* created, in my case it is lo:1 with IP address 10.34.25.162. It's netmask is 255.0.0.0, dunno where it is taken from - different IP addresses get different masks.

(In reply to comment #7)
> (In reply to comment #5)
> > Looking at the kernel ioctls, it looks like it is possible to add ipv6 address.
> > The kernel requires not only interface index and the IP address (both is known
> > to Net-SNMP), but also prefix length of the IPv6 address. This cannot be set
> > using simple snmpset and Net-SNMP does not have any clue what is the desired
> > prefix length. Can Net-SNMP assume that it is always 128?    
> 
> Hi,Jan 
> 
>  If we have to set the prefix length to a fixed value,as many test cases in
> TAHI show,64 may be a more common prefix length.But I think it's not the point
> to check.

Well, the goal is not to be TAHI compliant but to do what network admin needs. The compliance is only nice bonus, right? Assumption of network prefixes should be based on real world use-case, not on artificial test suite.

(In reply to comment #9)
> Well, the goal is not to be TAHI compliant but to do what network admin needs.
> The compliance is only nice bonus, right? Assumption of network prefixes should
> be based on real world use-case, not on artificial test suite.    

Hi,Jan
You are right,but I'm not so sure about the most common prefix length. According to this page:http://tools.ietf.org/html/draft-savolainen-stateless-pd-01 ,
it seems that 64 may be more common in real world,and you know that the ipv6address we always use consists of a 64  prefix  and physical address of a node.
But you could decide it :)

xiaoli

Hi,Jan
As page http://www.getipv6.info/index.php/IPv6_Addressing_Plans said (FYI),
   1.  Separate address block for infrastructure from other uses (enterprise, loopbacks)
          * May mean two /48s per PoP
          * Document so that you can justify it in your Host Density ratio 
   2. Each individual site should receive a /48 assignment which 65536 subnets (2^16).
   3. Summary aggregates for groups of sites where it makes sense, but watch your HD ratio
   4. Any prefixes shorter than /48 will only be assigned when there is written justification to show that this prefix will meet the RIR HD ratio guidelines within 5 years.
   5. Each PoP is a site therefore assign a /48 for infrastructure
   6. No subnets will use prefixes longer than /64.
   7. Separate address block for router loop-back interfaces
          * Generally number all loopbacks out of one /64
          * /128 per loopback
          * Note that this recommendation violates RFC4291 - "IP Version 6 Addressing Architecture", which states that for addresses with other than binary 000 as their first 3 bits, the Interface Identifier must be 64 bits long. It isn't really necessary to save IPv6 address space by using /128s on loopbacks. For example, out of a /48, if you allowed for 16384 /64s for loopbacks, you'd still have 49 152 subnets left for links. If your network is big enough that that sort of addressing plan is not going to be large enough, then you probably won't have any issues with getting multiple /48s e.g. a /47 or /46. 
   8. Assign a /64 per LAN / VLAN / subnet
   9. Organizations with multiple /48 allocations should consider enterprise-wise aggregation levels of /60 or larger blocks for the administration of enterprise policies for common functions such as:
          * DMZ
          * Realtime traffic, such as voice & video
          * Network loopback addresses and Link space 
  10. IETF expects that you will assign a /64 for point-to-point links
          * Fewer typos because all subnets are the same size
          * You can use longer prefixes but what's the point?
          * /126 will break Mobile IPv6 Home Agent discovery
          * /112 leaves final 16 bits free for Node IDs
          * Use /64 unless you have read and understand RFC 3627
          * Note: on pure point-to-point links (e.g., SONET) anything shorter than /127 is vulnerable to ping-pong packet amplification as described in Maz's APNIC 26 presentation. (On Ethernet, this is at most a neighbor cache DoS) 
  11. The enterprise network should receive a prefix sufficient to provide a /48 allocation for each site (office/campus/PoP) at which the company has employees or systems.
  12. All customers get one /48 unless they can show that they need more than 65k subnets.
          * Host count is irrelevant.
          * Do not assign to customers from PoP aggregates
          * Define aggregate areas which contain several PoPs
          * Carry customer networks in iBGP
          * Aggregate only in eBGP
          * If you have lots of consumer customers you may want to assign /56s to private residence sites. 
  13. Expect the registry to allocate a /32 and reserve one /32
          * Plan for the time when you get a second allocation giving you a /31 aggregate.
          * If you get more than /32 first time round, ask the RIR how much is reserved so you can plan appropriately. 
  14. If you need private addresses, generate a ULA prefix as defined in RFC 4193
          * Use this handy web tool to generate one
          * Add it to the registry at the above site, if you want people to know that this is your private space
          * Make sure your internal registry people are aware of your ULA prefix(es) so that everybody uses it. 

Thanks
 
xiaoli

Ok, let it be prefix /64. I'll try to prepare something for 6.1

I've created experimental patch and published RHEL6 test packages at http://people.redhat.com/jsafrane/bugs/616336/

Please test if it passes the test suite now. On my RHEL6 machine, I can create new IPv6 address using this (long) command:
$ snmpset  -v2c -c public localhost IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  integer  createAndGo IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2

The address can be deleted using:
$ snmpset  -v2c -c public rhel6 IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  integer  destroy


Only the 'createAndGo' method of creating new rows is supported, 'createAndWait' is not implemented in Net-SNMP.

(In reply to comment #13)
> I've created experimental patch and published RHEL6 test packages at
> http://people.redhat.com/jsafrane/bugs/616336/
> 
> Please test if it passes the test suite now. On my RHEL6 machine, I can create
> new IPv6 address using this (long) command:
> $ snmpset  -v2c -c public localhost
> IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 
> integer  createAndGo
> IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1
> IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1
> IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2
> 
> The address can be deleted using:
> $ snmpset  -v2c -c public rhel6
> IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 
> integer  destroy
> 
> 
> Only the 'createAndGo' method of creating new rows is supported,
> 'createAndWait' is not implemented in Net-SNMP.

Hi,Jan
I have tested this package:
http://people.redhat.com/jsafrane/bugs/616336/,

1) Yeah,IPv6Address could be created by the command 
snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0  i 4 IP-MIB::ipAddressIfIndex.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2 IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 1 IP-MIB::ipAddressStorageType.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 2
IP-MIB::ipAddressRowStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: createAndGo(4)
IP-MIB::ipAddressIfIndex.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: 2
IP-MIB::ipAddressStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: preferred(1)
IP-MIB::ipAddressStorageType.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00" = INTEGER: volatile(2)
2)
However it seems that the following two fields could not be set to value 3("not ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)

snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee  IP-MIB::ipAddressRowStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 3
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressRowStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00"

snmpset  -v 2c -c IPv6ReadyLogo IPv6Testee  IP-MIB::ipAddressStatus.ipv6.16.63.254.5.1.255.255.1.0.0.0.0.0.0.0.1.0 i 3
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: IP-MIB::ipAddressStatus.ipv6."3f:fe:05:01:ff:ff:01:00:00:00:00:00:00:00:01:00"

Thanks.

(In reply to comment #15)
> 2)
> However it seems that the following two fields could not be set to value 3("not
> ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)

In the Net-SNMP code I can clearly see that ipAddressStatus supports only 'preffered' (=1) state on snmpset operation. Is 'invalid' required by the test suite? What benefit to customer has adding invalid IP addresses?


And ipAddressRowStatus cannot be set using snmpset, see RFC 2579:
    
    RowStatus ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION
            ...
            Whereas five of the six values (all except `notReady') may
            be specified in a management protocol set operation, only
            three values will be returned in response to a management
            protocol retrieval operation

Only snmpd itself can set the status to 'notReady' when it has not enough information to add the IP address to physical network interface. And I am not sure if it can ever happen, since snmpd does not support createAndWait...

(In reply to comment #16)
> (In reply to comment #15)
> > 2)
> > However it seems that the following two fields could not be set to value 3("not
> > ready" for ipAddressRowStatus and "invalid" for ipAddressStatus)
> 
> In the Net-SNMP code I can clearly see that ipAddressStatus supports only
> 'preffered' (=1) state on snmpset operation. Is 'invalid' required by the test
> suite? What benefit to customer has adding invalid IP addresses?
> 
Hi,Jan
Thanks for your hard work to dig it, it's actually required by the test suite,but Maybe TAHI's test suite is not so perfect until now,and they may have some different understanding about the RFC, I'll talk about it with them.

> 
> And ipAddressRowStatus cannot be set using snmpset, see RFC 2579:
> 
>     RowStatus ::= TEXTUAL-CONVENTION
>         STATUS       current
>         DESCRIPTION
>             ...
>             Whereas five of the six values (all except `notReady') may
>             be specified in a management protocol set operation, only
>             three values will be returned in response to a management
>             protocol retrieval operation
> 
> Only snmpd itself can set the status to 'notReady' when it has not enough
> information to add the IP address to physical network interface. And I am not
> sure if it can ever happen, since snmpd does not support createAndWait...

Maybe TAHI need to modify their test suite.
Thanks.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0729.html