> > - limit in6_matchlen() to 64 for address selection. > > I agree that full-128bit comparison does usually not make much sense, > but I'm not sure if the assumption of the fixed prefix length is a > good idea...
I'm reasonably certain it's a bad idea - I fully expect that some sites will need to have prefixes > 64 bits, either because the ISP didn't follow the rules or they really need to subnet something hanging off a /64. I'm starting to think that rather than having all of these (address prefix and length) constants wired in to code, there might need to be a couple of configurable tables somewhere: one table might map prefixes onto address classes another table might be a matrix of source vs. destination address classes, mapping those to preference values for each of several conditions to be supplied by the app (does the app prefer privacy, address stability, proximity, global addresses, or what?) then the app would call a sort_addresses routine that ordered the various possible (source, destination) address pairs according to which ones seemed to best fit that app's requirements. but this is a huge mess. even if we might end up needing something like this, we really ought to work on reducing the number of addresses that an app is expected to deal with. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
