NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Robert Gilligan <gilligan@free-gate.com>
Tony Hain <tonyhain@microsoft.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Scott Bradner <sob@harvard.edu>
General Discussion:ngtrans@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: include "subscribe ngtrans"
Archive: ftp://playground.sun.com/pub/ngtrans
The purpose of this group is to design the mechanisms and procedures to support the transition of the Internet from IPv4 to IPv6.
The work of the group will fall into three areas:
1. Define the processes by which the Internet will be transitioned from IPv4 to IPv6. As part of this effort, the group will produce a document explaining to the general Internet community what mechanisms will be employed in the transition, how the transition will work, the assumptions about infrastructure deployment inherent in the operation of these mechanisms, and the types of functionality that applications developers will be able to assume as the protocol mix changes over time.
2. Define and specify the mandatory and optional mechanisms that vendors are to implement in hosts, routers, and other components of the Internet in order for the transition to be carried out. Dual protocol stack, encapsulation and header translation mechanisms must all be defined, as well as the interaction between hosts using different combinations of these mechanisms. The specifications produced will be used by people implementing these IPv6 systems.
3. Articulate a concrete operational plan for transitioning the Internet from IPv4 to IPv6. The result of this work will be a transition plan for the Internet that network operators and Internet subscribers can execute.
The group will use the Simple SIPP Transition (SST) overview document, draft-ietf-sipp-sst-overview-00.txt, as the starting point for its work on the IPv6 transition.
The group will work closely with the main IPng Working Group (IPNGWG) and the IPng Address Configuration Working Group (ADDRCONF). The group will co-ordinate with the TACIT group.
Goals and Milestones:
· A proposal for an IPv6 site database object
Request For Comments:
|
RFC |
Status |
Title |
|
RFC1933 |
PS |
Transition Mechanisms for IPv6 Hosts and Routers |
Minutes of the New Generation Transition (NGTRANS) Working Group
Reported by: Bob Fink RLFink@lbl.gov
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.
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. No registry bits are wasted; small blocks of TLAs will be handed out to various registries as appropriate.
This is critical. For the Federal networking addressing I work on, I'd like to have the IANA allocate a small block of TLAs, to NIST for example, 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 work with favors some type of geographic based addressing scheme.
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 can now 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 leaves only 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 1,000 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.
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 |
+---+---------+----------------+---------+---------------------------------+
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 that 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.
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 Working Group meeting later in the week. He postulated that, if real operational experience and feedback to developers and the IPng Working Group is 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 Working Group co-chair.
Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng Working Group meeting later in the week, and that this would result in an Internet-Draft shortly thereafter. 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 Network 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 that 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?