> -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 05, 2007 6:10 PM > To: Eliot Lear > Cc: Internet Area > Subject: Re: [Int-area] 240/4 > > On 5 dec 2007, at 16:27, Eliot Lear wrote: > > > * Nothing > > * Make the space a compile time option > > * Make the space a configuration option > > * Just turn it on > > > Dave is of the opinion that doing the latter (or having default > > enabled > > for the middle two) is akin to inviting the sorts of security concerns > > that have been raised about v6 deployment. > > Can anyone point me to the RFC that states that IP stacks are supposed > to be unable to use this space?
There's no RFC that defines how to use it. That is, it's neither unicast nor multicast nor broadcast. > This is quickly deteriorating into > silliness if we need positive proof that this space is useful and > secure before vendors are willing to remove obstacles against its use > that, in my opinion, were never supposed to be there in the first place. > > Having said that, it looks like telling people to remove the blocks > and then think about a use for this space is probably not going to be > a workable way forward. For the purposes of 6to4 and possibly others, > it's important to know whether this will be private or public space. > We know it probably can't be "real" public space because there will > always be boxes that will filter it, but there's still a difference > between public-with-practical-limitations and private-by-design. In > reality, it's probably going to be space for some very specific > purpose that doesn't easily fit into our public/private dichotomy. > > > I am less concerned about security considerations in this particular > > case, since devices could send packets with 240/4 sources or > > destinations NOW. > > Right. Or any other source or destination, for that matter. How would > receiving a 240/4 packet be worse than any other packet? For example, if your firewall software were somehow incapable of having filter rules for the 240/4 space where it could for other addresses, that would be a clear security hole. Any time you have a business-critical operational tool (whether IDS, firewall, traffic engineering, or whatever else) that would refuse to accept configuration for such an address, receiving 240/4 would clearly be worse than for any other packet. -Dave > > Alain Durand raised concerns that devoting resources to making 240/4 > > available, while others at the same time said they needed the space > > now > > for private purposes in a controlled environment. I would like to > > re-iterate what I said in the meeting, speaking for myself: there is > > no > > Plan B. We need to go to IPv6. The only question for me is how do we > > transition in an orderly and responsible fashion? > > In my opinion, the 240/4 and IPv6 issues are mostly orthogonal. They > only come together in as far as that keeping 7% of the IPv4 address > space "reserved" and then running out is very bad PR. The 240/4 block > won't be useful for regular applications and even if it were, > increasing the pool of free IPv4 addresses by 25% won't make the IPv4 > depletion issue go away, it just postpones the inevitable. A little. > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
