Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
RFC 4632
Discuss
Yes
Lars Eggert
(Alex Zinin)
(Brian Carpenter)
(David Kessens)
No Objection
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Magnus Westerlund)
(Russ Housley)
(Sam Hartman)
(Scott Hollenbeck)
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert
Yes
Margaret Cullen Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-02-16)
At this point, these are more questions/comments for the AD than specific issues to be addressed by the document authors: I share Ted's concerns about what it means to publish this as a Proposed Standard, as I don't see where this document defines a protocol or external behavior for IP nodes. Maybe BCP would be more appropriate? Also, I find it strange that this document doesn't even mention IPv6. IPv6 also uses CIDR-based address allocation, and I think that some of the conclusions will apply if/when IPv6 is widely-enough deployed to present route scaling issues. Also, is this document intended to advocate that the IETF should be working on an improved multihoming solution for IPv4? If so, how/where/when do we intend to undertake that work? I am somewhat concerned about publishing an IETF standards track document that says we need to do something that we don't have any specific plans to do.
Alex Zinin Former IESG member
Yes
Yes
()
Brian Carpenter Former IESG member
Yes
Yes
()
David Kessens Former IESG member
Yes
Yes
()
Allison Mankin Former IESG member
No Objection
No Objection
()
Bert Wijnen Former IESG member
No Objection
No Objection
()
Bill Fenner Former IESG member
No Objection
No Objection
()
Cullen Jennings Former IESG member
No Objection
No Objection
()
Dan Romascanu Former IESG member
No Objection
No Objection
()
Jari Arkko Former IESG member
No Objection
No Objection
()
Jon Peterson Former IESG member
No Objection
No Objection
()
Lisa Dusseault Former IESG member
No Objection
No Objection
(2006-05-19)
I note that this obsoletes a Standards Track document with a BCP. I don't see it written down anywhere that this is OK, but I don't see it forbidden either. I am happy to see RFC1519 replaced with more up-to-date information.
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Mark Townsley Former IESG member
No Objection
No Objection
(2006-02-15)
> simple, legacy end-site configurations, they are considered obsolete > and should NOT be used in transit networks connected to the global > Internet. Should there be RFC 2119 keywords in this document? It looks like there *almost* is here. > Similarly, routing and forwarding tables in layer-3 network equipment > must be organized to store both prefix and prefix length or mask. > Equipment which organizes its routing/forwarding information > according to legacy class A/B/C network/subnet conventions cannot be > expected to work correctly on networks connected to the global > Internet; use of such equipment is not recommended. Fortunately, > very little such equipment is in use today. is not recommended, or NOT RECOMMENDED. Again, are we using 2119 or not? > 1. Forwarding in the Internet is done on a longest-match basis. > This implies that destinations which are multi-homed relative to > a routing domain must always be explicitly announced into that > routing domain - they cannot be summarized (this makes intuitive > sense - if a network is multi-homed, all of its paths into a > routing domain which is "higher" in the hierarchy of networks > must be known to the "higher" network). When I read this, I hit a parsing error, incorrectly matching the two hyphens, and the two overlapping parens. Suggest less reliance on the hyphens here. > 2. Acceleration of the exponential trend in late 1993 and early 1994 > as CIDR "supernet" blocks were first assigned by the NIC and > routed as separate legacy class-C networks by service provider. > s/provider/providers > 5. A new period of exponential growth again from early 1999 until > 2001 as the "high-tech bubble" fueled both rapid expansion of > Internet as well as a large increase in more-specific route > advertisements for multi-homing and traffic engineering. s/Internet/the Internet
Ross Callon Former IESG member
No Objection
No Objection
(2006-05-24)
There has been a bit of "re-writing of history", when they say that the idea for CIDR came out of the ROAD effort. In fact Yakov came up with the idea when reading the NSAP address allocation draft -- basically Yakov recognized that the same ideas could be applied to the shorter IP addresses if you went classless. This was then taken into the ROAD effort when the concern came up that the other approaches that ROAD were discussing wouldn't be useful in the immediate short term. However, I don't think that this is important enough to put in a Discuss -- the authors can fix this if they want to or leave as is.
Russ Housley Former IESG member
No Objection
No Objection
()
Sam Hartman Former IESG member
No Objection
No Objection
()
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
(2006-02-14)
The document gives this bit of history: In the early days of the Internet, IPv4 address space assignment was performed by the central Network Information Center (NIC). Class A/B/C network numbers were assigned in essentially arbitrary order, roughly according to the size of the organizations that requested them. All assignments were recorded centrally and no attempt was made to assign network numbers in a manner that would allow routing aggregation. This does not match my memory. I believe the NIC assigned IPv4 address space sequentially within each of the network classes, not arbitrarily. While you could certainly say that this did not allow routing aggregation, since there is no necessary relationship between sequence of application and upstream, in fairness there was a single upstream for much of the time this was in place. Given how many networks use NAT in combination with CIDR, it seems surprising that the string " NAT " does not occur in the document; declaring a discussion of it explicitly out of scope might be useful.