Sangeeta Misra wrote: > Darren Reed wrote: > >> 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? >> > > Yes. Solaris in.routed code should be changed so that > - it considers a packet with a source address( or destination address) > of Class E space to be valid. > - considers a Class E address as a interface address to be valid. > > Note that 255.255.255.255 is still invalid in this context ( see below) > >> >>>> 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? > > > I will assume that you mean to say this: > > "ifconfig ce0 240.0.2.1 netmask 240.0.0.0 up" > > here ( then 255.255.255.255 becomes a valid network address for that > subnet) > > Note draft-fuller-240space-00.txt states: > ---------- > Note that the broadcast address, 255.255.255.255, still must be > treated specially in each case: it is illegal as a source IP address, > it is illegal as an network interface address, and it matches the > local system when used as the destination address in a received > datagram. > ------------- > Given that, I dont think that 255.255.255.255 should be considered to > be a valid Class E address. Also I assume IP reserves the entire range > of addresses from 255.0.0.0 through 255.255.255.255 for broadcast, and > this range should not be considered part of the normal Class E range. > > In searching the web I find that the range of valid Class E address > varies- Cisco docs state the range to be 240.0.0.0 - 254.255.255.255, > but others specify it as 240.0.0.0 - 255.255.255.254.
To PSARC: So this brings up a question - how do we approve a case where: - the primary spec is currently a draft (an IETF one at that) - defined by an outside body - the spec may change after the project completes (unlikely) Part of me wants to say it should be marked as needing spec. Or do we simply say that the project defines whatever it wants to be its spec, use the internet draft as a reference and if/when the RFC becomes published and there's a change, someone hopefully remembers and publishes another case that updates this one? Ideally what I'd like to see happen is when the draft becomes an RFC (and if there's no specification change) is for the case to be updated saying that there is alignment between the RFC and our implementation. Darren
