Brian E Carpenter wrote:
I could write quite a long essay on why this wouldn't work, either on the site whose network I used to manage until a few years ago, or on the intranet of my current employer.
Ah, you can think of cases where it won't apply. So can I. I also have run some large networks including going through the exercise of renumbering large portions with IPv4.
All the IPv6 addressing and renumbering proposals I have seen have had drawbacks -- usually relating to their managability, and in my opinion because they require excessive manual configuration where it is not required. Are we doing engineering here or searching for *the* solution matching some single perfect Platonic form? Pragmatically I think we need a variety of addressing and renumbering solutions with strengths that suit various environments. The important requirement is to ensure that they don't interfere with one another. > It's a neat trick, but it just doesn't match
the realities of network management and operations. It
implies, for example, that if you have to change a NIC
in a router, or swap a faulty router, subnet renumbering
will occur, with all its consequences for DNS, SNMP,
security policy and key distribution, and asset management databases.
I understand what you are saying. I am not against having a fully manually configured solution for large scale networks employing administrators. If a security policy has to be expressed in an addressing plan -- fine. I *do* want to see addressing solutions for un-administered networks that *don't* require manual configuration before anything gets off the ground. (scale larger than 1 link). I can also imagine the two co-existing. Address stability for critical infrastructure services can be achieved by manual allocated of a *few* subnets rather than requiring manual configuration of *all* subnets.
In any case, that size of network will need the same subnet numbering plan for globals and locals, to avoid driving the network operators crazy during fault analysis.
In case it is unclear, I am not advocating the abolition of manually configurable site local addresses.
There may be a class of smallish unmanaged networks where this would work, but even there I think there's a big DNS problem.
Right -- the zerouter scale rather than the world-wide network scale. I agree that there are problems getting the DNS configured in the first place, and problems whenever you renumber (whatever the cause: manual intervention, router card swap or for that matter a host NIC swap). I don't think this proposal makes it any worse. - aidan
Aidan Williams wrote:A draft is in the pipeline. Michel, you and Brian are missing the point that there is *no* administration of SLAs if we can use a MAC address to automatically number *each* *link* in a site with a site-local address. All this needs is a new addressing format. I think this addresses your GUSL requirements. There is no numbering plan to administer, new or old. This has no effect on the numbering plan you might use for globals. There is no common site-local prefix shared across the site. Site-local addresses prefixes are constructed without manual configuration. For each link, a router may automatically assign a site-local address from an EUI-48 (ie a MAC address) using the following address format: | 12 bits | 48 bits | 4 bits | 64 bits | +---------+------------------+----------+----------------------+ | fef | router device ID | sub ID | machine interface ID | +---------+------------------+----------+----------------------+ Figure 1: Address Format: fef0::/12 There is no 16 bit SLA subnet number to be managed! A router gets 16 subnets per EUI-48. It can use those to number links without ethernet or similar chips with 48 bit MAC addresses. Links with more than one router can have more than one automatically allocated site-local prefix. IPv6 supports that just fine. If you don't like sharing the existing site-local space with non-/48 addressing format we can use a different prefix, say fe00::/10. That has the advantage of increasing to 6 the number of sub ID bits. - aidan Michel Py wrote:Administrative nightmare. This one of these things in IPv6 where there is an explicit trade-off between allocation efficiency and simplicity. I agree that the 54 subnet bits we have for site-locals today is overkill, but anything less than 16 subnet bits is not good. In the case you have both site-local and global at the same time, you want to maintain subnet numbers: 2001:YOUR:BLOC:BEEF:INTE:RFAC:E_IDE:NTIF FEC0:0000:0000:BEEF:INTE:RFAC:E_IDE:NTIF ^^^^ Maintain subnet number Given the room we have in FEC0::/10, I don't see a reason to do otherwise. Michel.
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
