The content of the document and the questions below will be discussed at the RIPE meeting next week. Please bring your comments to the meeting.
Will do. Here are however the "content-oriented" comments I have off the top of my head.
1. Class D procedure - is the assignment of these within the scope of this procedure?
No, I don't think so. Aren't all D addresses allocated for IP Multicast?
2. The issue of non-contigous subnets (eg multihomed orgs using a subnetted Class B) and the potential difficulties thereof? do we wish to give advice on this
Possibly. Use OSPF as a routing protocol, possibly there is a need also to support variable-length subnet masks. OSPF routers usually does away with the class concept, and instead maintains each route as a combination of an address and a mask. OSPF has also been designated the "common" IP routing protocol (see RFC 1371). This should take care of the "non-contigous subnets" as long as all the subnets are located inside a single autonomous system (or within a single OSPF routing system).
2. Is there a need for a short Appendix describing how to find a NOC of Last resort (cf App 2 on service providers)?
Not sure. Possibly.
Recently there has been growing interest in the use of Class D numbers as well. These are used to create IP multicast addresses - ie if a system transmits a datagram to an address within a Class D network it will be delivered simulataneously to a group of hosts, rather than to a single host. IP multicasting has applications in the area of coperative working and conferencing, as well as (potentially) in the support of routing protocols. A Class D network number has the top three bits set - ie the top byte has the value 224 or greater.
There's class E (and even F, I think), which have been reserved for future use, but that's perhaps not worth mentioning (only causes more confusion).
By use of a non-default address mask, it is possible for the administrator of a Class B network number to break it down into a number of Class C ``subnets''. These could then, for example, be assigned one per department in a University, and routers could be used to connect these together. This would allow a site network to be broken down into a set of autonomous networks, whilst the network as a whole appears to the outside world to have a single (Class B) number.
I think it may lead to a confusion of terminology to refer to subnets of a class B network as "Class C subnets". At best they may be class-C-sized subnets, but as I'm sure you all know they need not be. I have several times come across users referring to their local subnet of a class B network number as a class C network number, which it isn't. So I think it's best to leave out the use of "class C" in connection with subnetting a class B addresses in the above paragraph and the subsequent paragraph in the document. I'm also not sure it's 100% correct to use the adjective "autonomous" about subnets of a network, since with older IP routing protocols and older and simpler IP routers the subnets of a network have to be directly connected to each other, so in a sense, the individual subnets are not "autonomous" since they depend on the rest of the subnets of the subnetted network. This requirement is relaxed when you have routers with support for OSPF (and possibly variable-length subnet mask support).
Subnetting is thus a technique of moving the boundary between the host and network number parts of an address. For it to be useful, the IP implementations of all end systems on the network involved must support it. All must also use the same, centrally defined address mask.
Well, subnetting can still be useful even though not all end systems have support for it. The solution to the problem of coping with subnet-impaired end systems is Proxy ARP. It's also not neccessarily true that all subnets of a network have to use the exact same subnet mask. In connection with OSPF I understand it is fairly common to implement variable-length subnet mask (VLSM) support. To support VLSM the corresponding IP forwarding engine has to be converted to do a "longest-prefix" match in the forwarding table instead of a direct match. The section on subnetting speaks mostly of subnetting class B network numbers. Examples and explanations with subnetting class C network numbers should perhaps be included, toghether with an explanation that the largest subnet you can construct from a C network has room for up to 62 (and not 126) hosts, and that these cover host numbers 65-126 and 129-190.
numbers: 192.100.100 - 192.100.103. These could be assigned to three different departments and a backbone, and a sin- gle router used to interconnect them, as shown in Figure 1. ...
192.100.100 (backbone) ===o==============o===============o============o=== | | | | +---+ +---+ +---+ +---+ Connection | r | | r | | r | | r | --> to service +---+ +---+ +---+ +---+ provider or | | | other ===o======== ===o========= ===o======== 192.100.101 192.100.102 192.100.103 (Dept A) (Dept B) (Dept C)
Figure 1: Interconnection of Class C Networks via a Backbone Network
There is no single router interconnecting the stub networks here...
- more than 32 network numbers (or subnets), AND
Well, the revision of RFC 1366 which was circulated earlier included proposed blocks of 64 and 128 class C networks, if my memory serves me. Not sure this should impact this document at this stage, though.
multiple LAN interfaces and IP routing software. This might be impractical in some cases, on the grounds of existing investment in equipment. It might also be impractical in a situation where the site network is multi-protocol and the routers cannot handle all the protocols involved. MAC level bridging might then be required, along with a single network number across the entire network.
The last couple of sentences seem to contracdict the subsequent paragraph. Multiprotocol routers and combined bridge/routers are fairly common devices these days.
In making the decision as to whether a Class B number is necessary, note that many purpose-built routers can bridge as well as route (so-called ``brouters''), so it may be possible to route IP whilst bridging other protocols. Note also that the ``supernetting'' development described in Appendix 1 means in theory that the use of IP routers on site can be avoided in the case where a suitable block of Class C network numbers has been assigned.
In this case you're talking of using "supernetting" on a local level. I'm not at all entirely sure whether that will work -- too many end systems have this built-in notion of class A, B and C, and will probably refuse to cooperate if you tell it that you have a 4-block of C's and a shorter netmask than the default of a class C network. I know that eg. some versions of FTP Software's PC/TCP software only ask how many bits there are in the subnet field, where 8 with a B address means a subnet mask of 255.255.255.0. I do not think you will be allowed to specify a negative value for this configuration parameter. It really would be nice, though, to be able to recommend such a usage, but I fear that it will be a long time before we'll be able to do so (perhaps too long to ever be able to do this for IPv4). In the Supernetting appendix little emphasis is put on the fact that supernetting and CIDR are mainly techniques of concern for network service providers, and that CIDR has mainly to do with *inter*-domain routing, at least as long as a network service provider uses default routing to the Internet at large. Regards, - Havard