Hi Kerry, Yes, they can be derived from PIO. But is there any possibility customers manually set subnet prefix?
Now, we disable SLAAC on the appliance (due to it provides important services like web proxy/cache, web filtering, traffic monitoring) and use the 3 parameters to configure IPv6 addresses. #ip -6 addr add <host-addr>/<prefix-len> dev eth0 #ip -6 route add default via <gw-addr> in our current design, the customer is allowed to set prefix-len to non-64 value like 65. But according to discussions in this thread, it seems to me we SHOULD NOT allow our customers to set prefix-len to non-64 value unless they assign an address starting with 000.(Ask again, should we allow our customers to assign an address starting with 000 in first place?) Are you saying we should only allow customers to set IID. let prefix-len and gw-addr derived from ND interactions? As I stated before, we are adding ipv6 feature to our product, we don't expect ipv6 will be used by majority of our customers ( IPv6 is disable by default on our products). But we want to do the right thing at the begining. THanks, washam 2011/7/17 Kerry Lynn <[email protected]>: > The subnet prefix generally comes from the router on the link > via Router Advertisements (e.g., Google radvd). It's not > something the customer needs to set. > -K- > > On Sat, Jul 16, 2011 at 12:02 PM, Washam Fan <[email protected]> wrote: >> >> THanks Kerry and Brian, >> >> Now we provide 3 parameters to our customers to configure a IPv6 >> address manually: 128bit address, subnet prefix and default gateway >> (optional, if it is provided, it should be within the same subnet with >> the 128bit address). Should we set subnet prefix to a fixed value 64 >> if the 128bit address starts with 001-111? >> (ipv6 is a new feature in our appliance, we don't have much >> experiences about it) >> Thanks, >> washam >> PS: should we allow our customer configure 128bit address starting >> with 000 in the first place? >> >> >> 2011/7/16 Kerry Lynn <[email protected]>: >> > Brian, you're quite right. I had in mind only one particular class of >> > IID. >> > Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs >> > with "u"=0. Also, RFC 3041 has been obsoleted; see RFC 4941 and >> > its errata if privacy issues apply in your situation. >> > -K- >> > >> > >> > On Fri, Jul 15, 2011 at 6:25 PM, Brian E Carpenter >> > <[email protected]> wrote: >> >> >> >> The authors of RFC 4291 chose not to use the upper case normative >> >> keyword convention defined in RFC 2119. Therefore, 'required' means >> >> what in means in plain English (i.e. REQUIRED in RFC2119ish). >> >> >> >> Brian >> >> >> >> On 2011-07-15 19:03, Washam Fan wrote: >> >> > Hi, >> >> > >> >> > I quoted this paragraph from RFC4291: >> >> > >> >> > For all unicast addresses, except those that start with the binary >> >> > value 000, Interface IDs are required to be 64 bits long and to be >> >> > constructed in Modified EUI-64 format. >> >> > >> >> > But I am not sure how to interpret the text in a correct way. >> >> > >> >> > If I assign an ordinary unicast address (except reserved anycast >> >> > addresses mentioned in RFC5453) to an interface and the address >> >> > doesn't start with 000, MUST the prefix be 64 bits? MUST the IID be >> >> > constructed in Modified EUI-64 format? >> >> > >> >> > We are providing WebUI for our customer to manually assign IPv6 >> >> > addresses, we want to do hygiene check before the actual move. >> >> > >> >> > Thanks in advance >> >> > washam >> >> > -------------------------------------------------------------------- >> >> > IETF IPv6 working group mailing list >> >> > [email protected] >> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> > -------------------------------------------------------------------- >> >> > >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> [email protected] >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> > >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
