> >> Unassigned: > >> > >> 6/8 + 57/512 (2.5521177519070384759753095557382e+38 > >> + > 3.788299787987010237775850121799e+37 > >> of addresses) > >> This is the remaining of the address space, which > has not > >> been assigned. > > for implementers, it needs to be known that the unassigned > region is > unicast addresses, not just "unassigned". > otherwise, implemnters cannot implement the code to handle these > "future allocation" addresses. in my understanding this is the > main reason for the wording change between RFC and i-d.
Second that. We have to be able to decide thinks like "address scope" and "address type", in order to implement requirements such as "addresses used in this context must be global scope unicast addresses." If we want compatibility with future assignments, that should not be done by testing for 200::/3... -- Christian Huitema -------------------------------------------------------------------- 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] --------------------------------------------------------------------
