> One substantial point I'd like to see more discussion on is whether folks > feel that "Address Format" section, mainly restating what addr-arch-v3-11 > says on 64 bit IID's, seems like the right thing to do in this document? > > I think this point was brought up by at least Thomas Narten and others, > but I don't remember whether a closure was reached. > > So, I believe everything starting from: > > [ARCH] also requires that all unicast addresses, except those that > start with binary value 000, have Interface IDs that are 64 bits long > and to be constructed in Modified EUI-64 format. The format of > global unicast address in this case is: > [...] > > should be removed, if not the whole section. > > I can live with this but IMO putting 64-bit-interface-ID thing which is > rather controversial still in too many documents seems like something to > be careful about.
The problem here is software implementation of longest prefix match. Up to this point it was limited to a few TLAs with 48 bits which was quite doable in software, this draft expands it to 61 and you are proposing 125, which is well beyond capabilities of software based lookups. I do not see anything specifically wrong with this approach if a complete enterprise router replacement is a stated goal of IPv6. If not then we have to address the issue of software based implementations somehow. Again, it may be a way to go, but frankly I am in a little shock - after many years of planing for various hierarchical partitions to find myself back in CIDR without borders environment and all of it in a matter of days. > Pekka Savola "You each name yourselves king, yet the Thanks, Aleksey -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
