below... Quality Quorum wrote: > > > 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.
I find this surprising. The decision to scrap TLA/NLA was taken a long time ago, and in any case it's always been clear that such boundaries were not architectural, but merely conventions in the address assignment scheme. So any implementation that takes any notice of TLA/NLA was broken anyway. The only boundary that should affect code is the /64 boundary, which is why the paragraph that Pekka cited is valuable. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
