Editor's Note: These minutes have not been edited. > Date: Tue, 15 Apr 1997 21:18:58 -0700 > From: Bob Fink > > 1. an exchange (like a NAP with extra functionality) can be registered as > well as a provider at the top-level. This makes it quasi geo/metro-like. > People getting their delegation from an exchange (as opposed to a provider) > will then arrange who will be their transit provider beyond the exchange > point of connection, and won't have to renumber as long as the exchange > operator stays in business. Maybe transit arrangements are also another > business opportunity for the exchange operator. I like this. > 2. the TLA (Top Level Aggregator) is limited to 13 bits to limit the > high-level routing complexity. no words yet on who gets to be one of > these...stay tuned. > > 3. no registry bits are wasted, small blocks of TLAs will be handed out to > various registries as appropriate. This is kind of critical. For the Federal networking addressing I'm working on, I'd like to have the IANA allocate a small block of TLAs to for example NIST, as the standards body for the US, who could then suballocate portions of this space to various federal organizations. The general consensus among the federal groups I am working with favors some type of geographic based addressing scheme. > 4. the IEEE EUI-64 was accepted, thus fixing the node id to 64 bits and > reducing the "routing goop" site prefix size to just 48-bits. With the > site partition (subnet) field being 16 bits it means that the routing is > now able to be done on 64 bits. I really don't like this at first glance. 64 bits of basically flat space for a given subnet seems like major overkill. I thought that 48 bits of flat space was overkill, but I could see the significant advantage to that. I don't see any advantage to increasing this to 64 bits and I do see a major disadvantage. The disadvantage is that it only leaves 32 bits for the NLA, which seriously reduces the flexibility of the RG. If you broke this down for example into 3 fields for provider, sub-provider, and site, each field would only be about 10 bits or about 1000 possibilities, and you might want to have more fields. For the geographic based scheme I was proposing as a strawman, I had 5 fields, namely region (10 bits), metro (10), locality (10), organization(10), and site (8), which adds up to 48 bits. Trying to squeeze something like this down into 32 bits would be quite difficult. > 5. the EUI-64 "global/local" bit will have significance in that if it is > set to "global" it may be treated as globally unique, while setting it > "local" will mean that it can then be formatted in a non-globally unique > fashion. Maybe I missed it in the web page reference, but I didn't notice any reference to the "global/local" bit, although I know they have this for EUI-48. Once again, I don't see any utility/advantage to using EUI-64. EUI-48 makes sense since it's used quite universally in Ethernet, FDDI, ATM, etc MAC layer addresses, but I've yet to see anything that uses EUI-64, and it just seems a monumental waste of valuable address space. > | 3 | 13 bits | 32 bits | 16 | 64 bits | > +---+---------+----------------+---------+---------------------------------+ > |010| TLA | NLA* | subnet | EUI-64 node id | > +---+---------+----------------+---------+---------------------------------+ > > TLA = Top Level Aggregator > NLA* = Next Level Aggregator > EUI-64 = http://standards.ieee.org/db/oui/tutorials/EUI64.html > > >I'm working on a Federal networks ATM addressing plan, and I'm proposing > >to use IPv6 addresses embedded in ATM NSAP addresses. I was originally > >planning to use a geographic based scheme, but perhaps I should check > >out this new addressing I-D to see what options it provides. The bottom > >line is I need real IPv6 addresses from some registration authority. > >Is a registry for the US / North America defined at this point for any > >of the addressing options? > > No registry exists at this time. We anticipate starting with a test TLA > for the 6bone so we can start testing this whole thing, including > delegation and renumbering, as soon as possible. As indicated earlier, I would like to see IANA allocate a small block of TLAs to someone like NIST, who could then suballocate addresses to US federal organizations. > Comments now appropriate from "all" on usability of EUI-64 for your > purpose. There is a registry for it. EUI-64 would make what I'm trying to achieve more difficult, since there's no longer a natural match with existing 48-bit MAC addresses, which the ATM addressing currently uses as the ESI. However, I'm not saying it's impossible, only that it's no longer as natural a fit. Also, for handling IPv4 addresses in ATM NSAP addresses, I was looking to embed the IPv4 address in the low order 32 bits of the ATM NSAP address (not counting the SEL field), with an appropriate IPv6 route prefix (RG) in the upper bits of the ATM NSAP address (not counting the AFI/ICD fields). I'll have to see how this can fit into the new aggregator based IPv6 addressing format. > Apologies if I've misrepresented any of Bob's ideas here, but it is > probably useful to have some interpretation of this plan while we are > waiting on Bob :-) I think it's quite useful. Thanks for sketching it out. I look forward to reading all the gory details when the I-D comes out. > Bob -Bill Editor's note: the following was submitted separately for the same WG. -------------------------------------------------------------------- > 7. Addressing beyond RFC1987 / Bob Fink > -------------------------------------------------------------------- > > Bob Fink briefly outlined his desire for the 6bone to follow the new IPv6 addressing plan that he expected to result from the IPng WG meeting later in the week. He postulated that, if real operational experience and feedback to developers and the IPng WG was a primary goal of the 6bone, that the 6bone should move quickly to adopt a new addressing plan and to test network renumbering. > > Jim Bound expressed his concern that users might not accept the concept of renumbering in the marketplace. > > Bob Fink then asked Bob Hinden to comment as IPng WG co-chair. > > Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng WG meeting later in the week, and that this would result in an Internet-Draft shortly therafter. He also supported experimentation with renumbering as a goal for the 6bone. > > Further discussion was deferred to the mail list. >From one B. Fink to another... :-) Any idea when this aggregate-based unicast addressing plan I-D will be available? Is this supposed to be a replacement for the geographic based addressing option (format 100) or yet another option? I'm working on a Federal networks ATM addressing plan, and I'm proposing to use IPv6 addresses embedded in ATM NSAP addresses. I was originally planning to use a geographic based scheme, but perhaps I should check out this new addressing I-D to see what options it provides. The bottom line is I need real IPv6 addresses from some registration authority. Is a registry for the US / North America defined at this point for any of the addressing options? -Bill