Again, Im not sure why any focus is being put on RIR policy. And at least within the ARIN RIR what subnet boundary delineates what has to be registered tends to be a moving target (this is not something we should be referencing). And as far as registering subnet use, I'm not sure where it becomes a headache since most of it is 80% automated for those that do IP Address administration. But yet, all this seems pointless to discuss since it really isn't anything technical that IETF documents need to contain.
What I do find interesting from a technical point of view and what I hope doesn't get lost in the mass of emails is this one aspect that Brian brought up and Jeffrey attempted to clarify: "I think what Brian was trying to point up is that mapping the IPv6 sub-netting scheme to an existing IPv4 sub-netting scheme would be easier of the number of low order bits below the prefix in an address is the same. For example, a IPv4 /24 with 8 low order bits below the prefix might be mapped to a /120 IPv6 address. Clearly, this could be abstracted to a scheme using 2 or 4 x (32 - IPv4 prefix length) low order bits in the IPv6 address, i.e., assign a /n, where n = 128 - 2 or 4 x (32 - IPv4 prefix length)." Cheers Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dunn, Jeffrey H. Sent: Tuesday, September 30, 2008 9:38 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sherman, Kurt T.; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Martin, Cynthia E. Subject: RE: what problem is solved by proscribing non-64 bit prefixes? Mike, Actually, you cannot just assign a /48 to each site. The RIR H-ratio requirements may make this infeasible. Further, each /48 (/56 for IANA) allocations must be registered with the RIR, which is an administrate headache. Finally, there is the issue of reverse lookup registration for sites. These are just the policy issues. I think what Brian was trying to point up is that mapping the IPv6 sub-netting scheme to an existing IPv4 sub-netting scheme would be easier of the number of low order bits below the prefix in an address is the same. For example, a IPv4 /24 with 8 low order bits below the prefix might be mapped to a /120 IPv6 address. Clearly, this could be abstracted to a scheme using 2 or 4 x (32 - IPv4 prefix length) low order bits in the IPv6 address, i.e., assign a /n, where n = 128 - 2 or 4 x (32 - IPv4 prefix length). Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:25 PM To: [EMAIL PROTECTED]; Dunn, Jeffrey H. Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sherman, Kurt T.; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Martin, Cynthia E. Subject: RE: what problem is solved by proscribing non-64 bit prefixes? > When managing such a scheme alongside an IPv6 prefix which needs to be > assigned to the same set of servers, which are all dual-stack, the > *number* of prefixes, their *relative* numbering, and the host > *addresses* within the prefixes, it is quickly apparent that use of > only /64 prefixes makes for a management nightmare, particularly if > renumbering of prefixes and/or servers occurs, e.g. re-balancing the > VLSM arrangement itself in IPv4-land. Given that in IPv6, you can justify allocating a /48 to each separate site, which gives you 16 bits to mirror the IPv4 subnet hierarchy, while maintaining 64 bit interface sddresses, I don't see a technical issue here. And I would really recommend that you upgrade all of your management systems to fully support IPv6 instead of relying on tricks like generating an IPv6 address by applying a transform to an existing IPv4 address. Then you have no technical issue at all. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
