Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
RFC 4632

Note: This ballot was opened for revision 04 and is now closed.

(Margaret Cullen) Discuss

Discuss (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.

(Brian Carpenter) Yes

(Lars Eggert) Yes

(David Kessens) Yes

(Alex Zinin) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

Comment (2006-05-24)
No email
send info
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.

(Lisa Dusseault) No Objection

Comment (2006-05-19)
No email
send info
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.

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2006-02-14)
No email
send info
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.

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Comment (2006-02-15)
No email
send info
>    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

Magnus Westerlund No Objection

(Bert Wijnen) No Objection