Sangeeta Misra wrote: > Darren Reed wrote: > >> How will the configuration of class E addresses be handled by routed? >> > > RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed > has both version) I will be filing a seperate RFE for Quagga to handle > Class E.
So this means in.routed will be modified to only announce configured class E networks using RIPv2? >> The relevant document from the IETF appears to be: >> http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt >> >> Can this draft please be included in the materials for this case? >> >> Eventually there will be an RFC for this but since we can't yet >> cite an RFC# (and drafts do expire), it would be good to include >> the relevant specification as it exists at this point in time. >> > OK. > >> One issue with the specification is that it lists class E as extending >> from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today >> used as all-ones broadcast address. > > I see the range to be 240.0.0.0 - 255.255.255.254 This seems to be in contrast with what the Internet draft above says, in that the class E space being made available for private use is 240.0.0.0/4 (or 240.0.0.0 - 255.255.255.255.) If I do "ifconfig ce0 240.0.2.1 netmask 255.0.0.0 up" happens, how will the system respond to ping packets addressed to 255.255.255.255 on other network interfaces? With the other inet_* functions being announced as obsolete, should we be thinking about doing the same for inet_addr() (255.255.255.255 will be a valid address after this) ? Darren
