RIPE DRAFT, hints for applicants

> 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