RE: what problem is solved by proscribing non-64 bit prefixes?

["Azinger, Marla" <marla.azinger at frontiercorp.com>]

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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of Dunn, Jeffrey H.
Sent: Tuesday, September 30, 2008 9:38 AM
To: michael.dillon at bt.com; briand at ca.afilias.info
Cc: alexandru.petrescu at gmail.com; ipv6 at ietf.org; rbonica at juniper.net; Steve_Eiserman at ao.uscourts.gov; Pasi.Eronen at nokia.com; Sherman, Kurt T.; draft-ietf-v6ops-addcon at tools.ietf.org; ralph.liguori at disa.mil; night at nist.gov; dougm at nist.gov; v6ops-chairs at tools.ietf.org; 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: michael.dillon at bt.com [mailto:michael.dillon at bt.com]
Sent: Tuesday, September 30, 2008 12:25 PM
To: briand at ca.afilias.info; Dunn, Jeffrey H.
Cc: alexandru.petrescu at gmail.com; ipv6 at ietf.org; rbonica at juniper.net; Steve_Eiserman at ao.uscourts.gov; Pasi.Eronen at nokia.com; Sherman, Kurt T.; draft-ietf-v6ops-addcon at tools.ietf.org; ralph.liguori at disa.mil; night at nist.gov; dougm at nist.gov; v6ops-chairs at tools.ietf.org; 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
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------