Hi Geoff, Let me try to bring you out of your state of confusion.
On 17/08/11 12:48 PM, "Geoff Huston" <[email protected]> wrote: > I am now very confused! > > The IANA IPv4 address registry > (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) > contains only 256 entries, where each entry describes an entire /8. There are > a number of /8s that have a single routing policy, (0/8, 127/8), but there are > a much larger number of cases where there is no single routing policy that is > applicable to all addresses in the /8 (e.g. 192/8). Correct. > > I note that this draft does NOT propose to change the format of the ipv4 It does not change the format of the IPv4 registry except to add the PRI column. It does allow the registry to select the granularity that best fits the /8 in question. From the IANA considerations section: " Implementation of this document further requires IANA to update the IPv4 and IPv6 address registries to use a granularity commensurate with the most specific entry in the address registry." > address registry, so I assume that the /8s in the IPv4 address registry will > remain. For a /8 which has a single routing policy intent, they will remain. For a /8 which has more specific prefixes that do not match it's parent PRI they should be listed as the example provides. > Given that the IANA IPv4 Special purpose address registry already > contains a routing scope, and the IANA IPv4 address registry only operates at The IANA registry doesn't only operate at the /8 level. It has been asked many times to make reservations at more specific levels. It makes only /8 allocations to the RIRs, which might be where your confusion is derived from. > the level of a /8 then for Ipv4 I'm left wondering exactly what is the > purpose of this draft with respect to IPv4 and the IANA IPv4 address > registries. How would it be applied to the IANA IPv4 address registry? (the > example in the draft is entirely unhelpful in so far as the address blocks in > the draft's example do not correspond to entires in any IANA IPv4 address > registry. Its an example of what a snippet of 198/8 might look like, given: 198.18.0.0/15 reserved for Network Interconnect Device Benchmark Testing [RFC5735] 198.51.100.0/24 reserved for TEST-NET-2 [RFC5737] Is that not obvious? > > So if it does not readily apply to the IANA IPv4 address registry, does it > apply to the IANA IPv6 registries? It does apply to the IANA IPv4 registry, and will also apply to the IPv6 registries. > > The IPv6 address space registry > (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml) > also appears to be inapplicable (side note - conventionally March is spelled > with a capital "M"). I'll feed the capitalization concern back into the IANA team. > The unicast registry appears to contain a list of unicast > address allocations to the RIRs, and the Special Purpose Address registry for > Ipv6 > (http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special- > registry.xml) already contains a routing scope field. > > So I'm left with the distinct impression that for whatever value a "routing > intent" may have in the IANA IPv4 and IPv6 registries, I simply cannot see its > applicability to the existing IPv4 and IPv6 IANA registries. i.e. I cannot > see any practical application of this instruction to the IANA as it relates to > the IANA-maintained IPv4 and IPv6 address registries and the granularity of > the registry entries maintained by the IANA. > Now that you might realize that the IANA registry deals with more specific entries than you normally associate, does this help your confusion and allow you to see the use in explicitly stating routing intent and a binary attribute? Cheers Terry _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
