Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2007 09:14:03 +0200

On 2007-08-07 16:15, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Redesignation of 240/4 from 'Future Use" to "Limited Use for Large Private Internets'
> 	Author(s)	: P. Wilson, et al.
> 	Filename	: draft-wilson-class-e-00.txt
> 	Pages		: 4
> 	Date		: 2007-8-7
> 	
>    This document directs the IANA to designate the block of IPv4
>    addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast
>    address space for limited use in large private Internets.

It seems to me that we first need a discussion about why this space can't
be released as public address space. Is it known to be already deployed
as de facto private space?

I'd be a bit nervous about unintended side effects if
DHCP assigned me 255.255.255.255/32.

     Brian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 8 Aug 2007 10:40:21 +0300

On Wednesday 08 August 2007 10:14:03 ext Brian E Carpenter wrote:
> > 	Title		: Redesignation of 240/4 from 'Future Use" to "Limited Use for
> > Large Private Internets' Author(s)	: P. Wilson, et al.

Some widespread IPv4 stacks refuse to handle these addresses, so nobody would 
ever want to use them on the public IPv4 Internet.

---

C:\>ver

Microsoft Windows XP [Version 5.1.2600]

C:\>ping -n 1 247.1.2.3

Pinging 247.1.2.3 with 32 bytes of data:

Destination specified is invalid.

Ping statistics for 247.1.2.3:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

---

% uname -ro
2.6.22-8-generic GNU/Linux
% ping 247.1.2.3
connect: Invalid argument

-- 
Rémi Denis-Courmont

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2007 09:50:15 +0200

On 2007-08-08 09:40, Rémi Denis-Courmont wrote:
...
> ever want to use them on the public IPv4 Internet.

That will be a bit of a challenge in private networks too :-)

     Brian

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Aug 2007 10:16:44 +0200

Brian E Carpenter writes:
>> Some widespread IPv4 stacks refuse to handle these addresses, so 
>> nobody would ever want to use them on the public IPv4 Internet.
>

Much smaller. If example.com wants to use them, example.com will have to 
upgrade its own computers and routers to a version which supports this 
new class E. Nontrivial, rather expensive, but doable.

If you were to get 240.24.42/24 from your RIR, most/all of the public 
internet would have to upgrade before you could use the addresses. 
(Kind of like IPv6 but with a piddly little address space.)

Arnt

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Aug 2007 12:02:37 +0200

What happened to draft-hain-1918bis-01, which tried to get more address 
space for private Internets, but expired back in 2005?

I see the point about regarding 240.0.0.0/4 as "tainted space" and 
therefore being less than useful on the public Internet.....

                   Harald

Brian E Carpenter wrote:
>>     Title        : Redesignation of 240/4 from 'Future Use" to 
>> "Limited Use for Large Private Internets'

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Aug 2007 12:20:37 +0200

On Aug 08 2007, at 10:16, Arnt Gulbrandsen wrote:

> If example.com wants to use them, example.com will have to

Cheaper to use IPv6, then.
Non-starter, I'd say.

Gruesse, Carsten

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Aug 2007 12:54:30 +0200

> Cheaper to use IPv6, then.

I'm not sure using this class e thing + ipv6 is significantly more 
expensive than using either alone, so we may be looking at way to let 
some people transition with less pain: A big network can grow bigger 
before some hosts have to use pure 6.

Whether that makes the reclassification worthwhile is another matter.

Arnt

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Aug 2007 10:32:57 -0400

seems like the last thing the Internet needs is more private address
space. 

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 8 Aug 2007 10:18:11 -0700

Which widespread IPv4 stacks?
 
Given that we have a shortage of IPv4 space I cannot see how we could possibly put a quarter billion IPv4 addresses beyond use just because a number of unspecified IPv4 stacks have issues.
 
Rather than wall off the space as private and thus put it beyond any use we should think about what other uses we might be putting it to.
 
>From a PR point of view this plays very baddly. It reads as IPv6 zealots eagerly bringing the crisis point nearer by a notch. 

We need to change the way that this transition is being managed Unless we get the stakeholders round the table and stop trying to dictate terms through technical unilateral specifications we are going to end up with the result that we like least and are trying to avoid.
 
The wargames do not point to an inevitable transition to IPv6. If you play them honestly they lead to a heavily NAT-ed model where the large ISPs are free to re-establish the walled garden model that keeps re-appearing.
 
This is brinksmanship diplomacy. It has a very poor record.

________________________________

From: Rémi Denis-Courmont [mailto:[email-masked]]
Sent: Wed 08/08/2007 3:40 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt

---

C:\>ver

C:\>ping -n 1 247.1.2.3

---

% uname -ro

--
Rémi Denis-Courmont

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Aug 2007 10:35:39 -0700

On Aug 8, 2007, at 3:02 AM, Harald Alvestrand wrote:

> What happened to draft-hain-1918bis-01, which tried to get more  
> address space for private Internets, but expired back in 2005?
>

RFC 3330 listed as not currently part of the public Internet:

0.0.0.0/8	"this" 		 16,777,216
10.0.0.0/8	"private"	 16,777,216
127.0.0.0/8	"loopback"	 16,777,216
169.254.0.0/16	"link-local"	     65,536
172.16.0.0/12	"private"	  1,048,576
192.0.2.0/24	"test-net"	        256
192.168.0.0/16	"private"	     65,536
192.18.0.0/15	"benchmark"	    131,072
224.0.0.0/4	"multicast"	268,435,456
240.0.0.0/4	"reserved"	268,435,466
                              -------------
                                587,569,816 (13.68% of total non-public)
                              4,294,967,296 (total)
                              3,707,397,480 (addresses public)

Some larger providers and private organizations who depend upon  
private IPv4 addresses have complained there is no suitably large  
"private" IP address range which can assure each user within their  
network can obtain a unique private IP address.  It would seem class  
E could, and might already, function as a larger "private" IP address  
range.

-Doug

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Aug 2007 13:52:03 -0400

> 224.0.0.0/4	"multicast"	268,435,456

This is simply wrong. Multicast is certainly part of the public  
Internet, it is certainly used on the
public Internet and (I might point out) people (including yours  
truly) make money from it.

Regards
Marshall Eubanks

> network can obtain a unique private IP address.  It would seem  
> class E could, and might already, function as a larger "private" IP  
> address range.
>
> -Doug
>
>
>
>
>
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Aug 2007 11:03:59 -0700

On Aug 8, 2007, at 10:52 AM, Marshall Eubanks wrote:
>>> I see the point about regarding 240.0.0.0/4 as "tainted space"  
>>> and therefore being less than useful on the public Internet.....
>>

You are right.  Indeed Multicast is part of the public Internet.  The  
concern has been with respect to availability of general purpose  
public IP addresses, where multicast would be excluded as would  
private IP addresses.  This should have read "not currently part of  
the 'general use' public Internet."

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Aug 2007 11:09:27 -0700

>RFC 3330 listed as not currently part of the public Internet:

I have elided the table that Doug posted. Doug: the sentence above 
made it sound like your table was taken from RFC 3330. It was not. 
And, as others have pointed out, your table was wrong.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Aug 2007 11:12:34 -0700

At 10:18 AM -0700 8/8/07, Hallam-Baker, Phillip wrote:

And then you quoted a message that shows examples of some
stacks:

C:\>ver

C:\>ping -n 1 247.1.2.3

Packets: Sent = 1, Received = 0, Lost = 1 (100%
loss),

---

% uname -ro

2.6.22-8-generic
GNU/Linux

% ping
247.1.2.3

connect: Invalid
argument

How many more do you think we need?

--Paul Hoffman, Director

--VPN Consortium

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 8 Aug 2007 12:20:01 -0700 (PDT)

On Wed, 8 Aug 2007, Douglas Otis wrote:

> Some larger providers and private organizations who depend upon private IPv4 
> addresses have complained there is no suitably large "private" IP address 
> range which can assure each user within their network can obtain a unique 
> private IP address.  It would seem class E could, and might already, function 
> as a larger "private" IP address range.

They also need to route it locally. Guess what kind of problems they'd
run into...

BTW, even if this draft were implimented (which would require changes to
many operating systems, firewalls and local sites configs), it would just 
delay ipv4 exhausting by about 2 years, not allow to avoid it. What should
be done is greater effrot to migrate to ipv6 including supporting ides
like (some are from ppml):
   1. requirying at all RIRs that new ipv4 requesters include data on
      plans to migrate to ipv6.
   2. policy in all RIRs to make it very easy for any existing ipv4
      holder to get ipv6 block with no additional fees
   3. for vendors have ipv6 on by default on new systems and have it
      complain when it can not get ipv6 address from dhcp or can not
      do ipv6 routing, etc. That would put pressure on ISPs who will
      be asked about ipv6 more and more
   4. requirements for ipv6 for renew of ISP contacts by government
      and educational institutions (also more pressure to ISPs)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 8 Aug 2007 11:25:47 -0700

If a cable NAT box could survive on a tainted IPv4 we might well be able to find a use for them.
 
I don't see how the addresses are any more viable as private space as public.
 
Given the stakes with IPv4 allocations I would like to see a technical strategy in which the optimal course of action for all parties is to progress towards an orderly IPv6 transition. 

I do not beleive that transition to IPv6 is Pareto optimal today.
 
I don't think that it makes sense to consider re-allocating any address space until we have such a strategy defined. It might make sense to tell IP stack providers that they should regard the block as routable IPv4 uncast at this point. I don't think it likely that we would roll out any new capablility for IPv4 at this point.

From: Paul Hoffman [mailto:[email-masked]]
Sent: Wed 08/08/2007 2:12 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: I-D ACTION:draft-wilson-class-e-00.txt

And then you quoted a message that shows examples of some stacks:

	C:\>ver

	C:\>ping -n 1 247.1.2.3

	
	
	---
	
	% uname -ro

	% ping 247.1.2.3

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 8 Aug 2007 11:37:46 -0700

If this really would buy us even a single year then we have to do it. Two years is the difference between a train wreck and an orderly transition.
 
The question is whether we can buy any time with this change. That does not look very hopeful. But there might be opportunity.
 
I certainly don't think that we should conclude on the basis of two data points that we should just abandon the whole address space.

The point about requiring a transition plan to IPv6 might be a good one. I don't imagine that it would be very effecitve in coercing change but it could be effective in causing the hardware providers to converge on support for a viable transition strategy.
 
This is politics, we need much more than an engineering strategy dictated from on high by a group with no members and no constituency. 

We need to get some real economists involved here and some real lawyers. We do have some net-savy lawyers on tap, but economists are going to be harder to find, or rather they are going to be easy to find but not so easy to find good ones who are not peddling some ideology.
 
Perhaps the folk at the LSE who designed the auction of wireless spectrum for George Brown could help?
 
What I want to know is how we establish the incentives that are necessary to create the intended outcome. 

From: william(at)elan.net [mailto:[email-masked]]
Sent: Wed 08/08/2007 3:20 PM
To: Douglas Otis
Cc: Harald Alvestrand; IETF discussion list
Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt

--
William Leibzon
Elan Networks
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Aug 2007 13:22:30 -0700

Hi,

> Which widespread IPv4 stacks?

I think it might be easier to identify stacks that don't disallow  
240/4.  I don't actually know of any widespread ones.

> Rather than wall off the space as private and thus put it beyond  
> any use we should think about what other uses we might be putting  
> it to.

Calling address space private obviously does not "put it beyond any  
use".  In fact, there are folks out there who are burning public IP  
address space for internal infrastructure that could instead be using  
private space but can't because their internal infrastructures are  
too large.

Regards,
-drc

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Aug 2007 16:40:13 -0700 (PDT)

> We need to get some real economists involved here and some real lawyers. We
> do have some net-savy lawyers on tap, but economists are going to be harder to
> find, or rather they are going to be easy to find but not so easy to find good
> ones who are not peddling some ideology.
 
I think getting some real economists involved is an excellent idea. As you say,
ideology-peddlers (of all stripes) need to be avoided, but having some people
who think about this from an economic perspective could be HUGELY beneficial.

> Perhaps the folk at the LSE who designed the auction of wireless spectrum for
 
It may not be the right group but it's a place to start.

> create the intended outcome.

Exactly. For example, you might do something like make IPv4 allocations
cheaper, or easer to get, or something along those lines, in exchange for
deploying IPv6. (*) Perhaps this pool of addresses would best be saved for
possible use as an incentive...

BTW, I suspect you are correct about about the IPv6 transition not being Pareto
efficient at the present time, but IMO the bigger issue is that it is widely
percieved as not even being Kaldor-Hicks efficient, due in large part to
address space exhaustion being seen as an externality. Of course that will
eventually change, but it still may not drive things in the direction we want,
and even if it does the resulting transition period will be a real mess.

				Ned

(*) The example was Chris Newman's idea, not mine. And it is just an example -
neither Chris nor I are economists and neither of us are making an actual
proposal for an incentive here.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Aug 2007 19:05:44 -0700

On Aug 8, 2007, at 1:22 PM, David Conrad wrote:

> address space for internal infrastructure that could instead be  
> using private space but can't because their internal  
> infrastructures are too large.

The long term view for IPv4 employment should be an address space  
primarily used by internal networks.  IPv4 is supported by a large  
array of SOHO equipment that will not disappear anytime soon.  A near- 
term solution for IPv4 exhaustion will likely involve routers  
bridging between either private or public IPv4 address space into an  
Internet consisting of a mixture of IPv6 and IPv4.  Internal use of  
IPv4 should accommodate internal deployments exceeding 16 million IP  
addresses.  With rapid expansion of network equipment, 268 million  
addresses represents a far more reasonable range of addresses that  
rangers which are likely to be employed internally.

Such a larger range of internal addresses could even encourage use of  
older IPv4 router equipment to support these larger internal  
networks.  An aggressive strategy using this approach could be far  
more effective at postponing an enviable exhaustion of IPv4 addresses  
than would a year to few months reprieve a public assignment of the  
Class E space might provide.  Not having a larger IPv4 private  
address space will cause existing IPv4 equipment to be less valuable  
when it can only be utilized within extremely limited address ranges  
by any particular organization. : (

BTW, there is a typo after

2.  Caveats of Use

   Many implementations of the TCP/IP protocol stack have the
   204.0.0.0/4 address...

This should have been 240.0.0.0/4 addresses.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Aug 2007 03:20:22 +0100

Not that I want to be in this argument, but I was intrigued by the
name-dropping from folks who're not silly...

Ned Freed wrote:
> address space exhaustion being seen as an externality. 

So there is a nice Wiki page about both, but the one about the latter
says in part:

"Another problem with Kaldor-Hicks efficiency is that it only considers
private property and private income but does not take into account
change in value of the Commons, Natural Environment, and other
Externalities."

So, in this case, neither measure of efficiency blindingly obviously
applies (the latter being a genaralisation of the former) since the
items in question are very much part of a commons, natural environment
or, whatever it means, an externality.

The discussion about which stacks don't/could support these addresses
in what timeframe, is more interesting IMO.

S.

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Aug 2007 20:17:03 -0700 (PDT)

> name-dropping from folks who're not silly...

Thanks for the compliment, I guess...

> change in value of the Commons, Natural Environment, and other

I hadn't read the Wikipedia page on this before today, and IANAE, but this
doesn't seem quite right to me. In particular, my understanding is that whether
or not something is an externality depends on how the system is defined. I
think this page (which was next in line in Google) explains it all better:

http://www.reckon.co.uk/open/Pareto_improvements_and_Kaldor-Hicks_efficiency_criterion

> or, whatever it means, an externality.

I don't think so... The "efficency improvement" we're talking about here is
someone switching from IPv4 to IPv6. We're both saying that we believe that
under current conditions this is not "efficient" in either the Pareto
efficiency sense, which basically just looks at whether or not the move
benefits the person making the improvement while not hurting anyone else, or in
the sense of Kaldor-Hicks, which allows for harm to others as long as there's
an overall gain.

A point made on the Wikipedia page (and with which I agree) is that
Kaldor-Hicks is essentially a form of cost-benefit analysis. While you might
argue that the way people perform these analyses uses different criteria than
Kaldor-Hicks implies, I don't think you can make a case that people
contemplating such a change don't look at costs and benefits in some way.

> in what timeframe, is more interesting IMO.

My reason for commenting on this thread was to support PHB's assertion that
getting some people with serious ecomonic chops involved would be a good idea.
My remarks about efficiency were at most a side note - I'm sorry it has turned
the discussion away from what IMO is the more important point.

As for the address issue, I have to agree with PHB here as well: If these
addresses are usable in a reasonable time frame then we shouldn't be quick to
give them up for private use and if they are unusable in a reasonable time
frame it really doesn't matter what we do with them. So I guess the question
about stack support in different timeframe is interesting at least in the sense
that it would tell us whether or not this is even worth the electrons we're
using talking about it.

				Ned

---

From: Geoff Huston <[email-masked]>
Date: Thu, 09 Aug 2007 14:37:04 +1000

> that it would tell us whether or not this is even worth the electrons we're

"useable" is not a constant here.

"useable" in the sense of the context of the public internet implies 
every host in the public Internet should be able to generate a packet 
with one of these addresses in the destination field be able to send it 
out an interface, every host in the public Internet should be able to 
receive a packet with one of these addresses in the source field, and 
every router in the public Internet should be able to forward a packet 
with one of these addresses in the source and/or destination field (and 
every firewall, NAT and other pieces of middleware).

"useable" in a private context implies taking the above statement and 
/s/public Internet/private use context/

It should be evident that this distinction could be quite significant in 
certain private use contexts.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 9 Aug 2007 07:38:41 -0400

> 240/4.  I don't actually know of any widespread ones.

I had a specific idea for 240 and asked around and didn't find any  
either. So, this means a year or two to
develop and deploy at best, and probably a fork-lift upgrade at that,  
which does not seem that attractive.

If someone came out with a specific idea backed by hardware, though,  
is there a reason not to let
them go forward ?

Regards
Marshall

---

From: Daniel Senie <[email-masked]>
Date: Thu, 09 Aug 2007 12:05:50 -0400

>is there a reason not to let

If the IETF published an RFC that reassigned 240/4 to private address 
space usage today, it would likely be possible for enterprises to use 
it within a reasonably short period, perhaps a year or so, depending 
on how many vendors they work with, and their ability to assert pressure.

Let's look at the reality of software stacks in the present time. 
Micorosoft updates desktops and servers weekly or more often, and 
people are fearful enough of security matters that they do apply 
them. Linux vendors similarly release patches quite often. Router 
vendors seem to have new software for one fix or another daily.

If enterprises started working toward a deployment of pieces of 
240/4, vendors would make it possible.

A few of us looked at the Class-E issue some years ago, and thought 
it was worthwhile at that time to reclassify the space. Everyone 
understood it would take some time before the space was widely usable.

If there's to be any use of the space, ever, a scenario that would 
get us to usability might be:

- Reclassify Class-E space as usable address space

- Enable a few pieces of 240/4 as private address space use. Let 
people start using that.

- Enterprises, if there's interest will push vendors to make changes to stacks

- In a few years, evaluate whether the space is viable for public 
assignment by ARIN, et. al.

Even if the initial use of such space is limited to a few platforms 
and routers, it may be sufficiently useful to enterprises to use in 
private interconnects between companies, an area where significant 
difficulties are encountered today due to address re-use.

There will of course be a chorus of responses that if changes are 
required anyway, folks should just migrate to IPv6. The 
counter-argument I'd make is simple: the changes required in IP 
stacks to enable Class-E as valid addressing is minimal, resulting in 
little new code, and thus little risk from untested code. Initially 
allowing blocks from this space as additional RFC1918-style space 
would provide a playground where enterprises, users and vendors could 
test their wares, without risk to the public Internet.

For enterprises, the migration to IPv6 will be slow. The protocol 
stacks from all of the vendors are largely untested. I don't mean 
they haven't run code coverage, had QA teams and even 
interoperability testing. I mean there is limited experience with 
wide scale networks, high traffic volumes, exposure to denial of 
service and probing attacks. There will be vulnerabilites, just as 
there is with any code that's relatively new.

As I believed several years ago, reclassifying 240/4 is worthwhile. 
Leveraging the need of enterprises for additional, sanctioned, 
private IPv4 space for interconnects may result in widescale 
implementation. Or it might not. The point is, it would be relatively 
simple to find out, and would not be overly distracting to the IETF 
or to efforts to migrate to IPv6 .

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 9 Aug 2007 12:15:55 -0400

Hello;

On Aug 9, 2007, at 12:05 PM, Daniel Senie wrote:

> If the IETF published an RFC that reassigned 240/4 to private  
> address space usage today, it would likely be possible for  
> enterprises to use it within a reasonably short period, perhaps a  
> year or so, depending on how many vendors they work with, and their  
> ability to assert pressure.
>

I am specifically interested in assigned 1918 type space. In some  
applications, Enterprises need to connect
directly, and having to deal with multiple address overlaps in 1918  
space is a pain, to put it mildly. It would be
nice if there was a 1918 RIR type entity that handed this out only  
for use off the public Internet.

The other solution is to do this in PI space, which seems a waste.

Regards
Marshall

> required anyway, folks should just migrate to IPv6. The counter- 
> argument I'd make is simple: the changes required in IP stacks to  
> enable Class-E as valid addressing is minimal, resulting in little  
> new code, and thus little risk from untested code. Initially  
> would provide a playground where enterprises, users and vendors  
> could test their wares, without risk to the public Internet.
>
> implementation. Or it might not. The point is, it would be  
> relatively simple to find out, and would not be overly distracting  
> to the IETF or to efforts to migrate to IPv6 .
>
>

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 9 Aug 2007 12:23:17 -0400

This seems like the best course of action. Allocate 240/6 for private
use as soon as practical and hold the rest of the E Class for private or
public use as seems best later.

Donald

-----Original Message-----
From: Daniel Senie [mailto:[email-masked]] 
Sent: Thursday, August 09, 2007 12:06 PM
To: Marshall Eubanks
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-wilson-class-e-00.txt

...

If the IETF published an RFC that reassigned 240/4 to private address 
space usage today, it would likely be possible for enterprises to use 
it within a reasonably short period, perhaps a year or so, depending 
on how many vendors they work with, and their ability to assert
pressure.

- Enterprises, if there's interest will push vendors to make changes to
stacks

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Aug 2007 09:36:37 -0700

Marshall,

On Aug 9, 2007, at 4:38 AM, Marshall Eubanks wrote:
> If someone came out with a specific idea backed by hardware,  
> though, is there a reason not to let
> them go forward ?

I suspect it would be hard to say without knowing what the idea is...

Rgds,
-drc

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 9 Aug 2007 12:48:37 -0400

On Aug 9, 2007, at 12:37 PM, todd glassey wrote:

> Its not all wrong - only the Multicast Address space is mislabeled...
>

ACK, but that is what I was referring too...

Marshall

> T
> ----- Original Message ----- From: "Marshall Eubanks"  
> <[email-masked]>
> To: "Douglas Otis" <[email-masked]>
> Cc: "Harald Alvestrand" <[email-masked]>; "IETF discussion  
> list" <[email-masked]>
> Sent: Wednesday, August 08, 2007 10:52 AM
>>> private IPv4 addresses have complained there is no suitably  
>>> large  "private" IP address range which can assure each user  
>>> within their  network can obtain a unique private IP address.  It  
>>> would seem  class E could, and might already, function as a  
>>> larger "private" IP  address range.
>>>
>>> -Doug
>>>
>>>
>>>
>>>
>>>
>>>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Aug 2007 11:11:44 -0700

On Aug 8, 2007, at 12:20 PM, william(at)elan.net wrote:
>> class E could, and might already, function as a larger "private"  
>> IP address range.
>
> They also need to route it locally. Guess what kind of problems  
> they'd run into...
>
> BTW, even if this draft were implemented (which would require  
> changes to many operating systems, firewalls and local sites  
> configs), it would just delay ipv4 exhausting by about 2 years, not  
> allow to avoid it. What should be done is greater effort to migrate  
> to ipv6 including supporting ideas like (some are from ppml):
>   1. requiring at all RIRs that new ipv4 requesters include data on

It would appear both you and I are in agreement with the draft.

See:
http://www.apnic.net/mailing-lists/sig-policy/archive/2007/08/ 
msg00005.html

The draft classifies Class-E as "Limited Use for Large Private  
Internets".

This range should not be divided into smaller regions as some  
suggest.  Large Private Internets that bridge into a IPv4/IPv6 Public  
Internet represents a well considered long-term strategy.  Declaring  
this range available for use by Large Private Internets will expedite  
a reduction in the dependence and use of public IPv4 addresses.  A  
bridge into the private IPv4 address space can map into unique IPv6  
addresses while utilizing existing local equipment.  (Yankee thrift.)

IPv6 is how IP address exhaustion is prevented.  Assigning Class-E as  
"Limited Use for Large Private Internets" provides a far less painful  
transition to IPv6.  Adoption of this draft will help forestall an  
acceleration in IPv4 assignment rates.  At present, allocating this  
range for public use will likely afford much less than a year.   
However, not declaring this range as private will deprive large  
organizations and providers of a very attractive IPv6 transition  
strategy.  Once it becomes clear how this range of IP addresses might  
be used in conjunction with IPv6, broader adoption of IPv6 is more  
likely to occur with far less cajoling.

-Doug

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 9 Aug 2007 21:11:00 +0200

Douglas Otis writes:
> The draft classifies Class-E as "Limited Use for Large Private  Internets".

What large private internets are these, really? Are we discussing Google 
potentially needing more than one /8 for its web servers, or are we 
discussing providers (DSL, Wimax, 802.11, GSM, 3G or other) giving 
customers addresses from 240/4 via DHCP or PPP?

Employees using 240/4 is one thing. Your mother-in-law getting 
247.1.76.22 from her cable modem is quite another.

Arnt

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Aug 2007 16:06:06 -0400

It's not just host stacks and routers that would be impacted by this
change.  Some applications recognize RFC 1918 addresses and treat them
specially, realizing that they don't work like ordinary IP addresses. 
Such applications would need to be updated if another block of private
addresses were created.

It seems like the last thing we need is another set of private addresses
in IPv4 space, especially when use of such addresses is likely to result
in even more flakiness because of stack, router, and application
assumptions.  The existing arrangement with RFC 1918 addresses and NATs
(sometimes multiple layers of NATs) is already flaky enough, and reuse
of addresses already makes diagnosis of problems more difficult than it
needs to be. 

(of course, that might make IPv4 so unusable that people would be forced
to migrate to IPv6, which would be a Good Thing.  but I don't like the
idea of deliberately making IPv4 flakier.)

If these addresses are going to be reclassified, they should either be
public addresses (so that when problems did occur the nature of the
problem would be relatively clear), or reserved for very limited uses
that won't impact legacy hosts and applications.

Keith
> people are fearful enough of security matters that they do apply them.
> Linux vendors similarly release patches quite often. Router vendors
> seem to have new software for one fix or another daily.
>
> If enterprises started working toward a deployment of pieces of 240/4,
> vendors would make it possible.
>
> A few of us looked at the Class-E issue some years ago, and thought it
> was worthwhile at that time to reclassify the space. Everyone
> If there's to be any use of the space, ever, a scenario that would get
> us to usability might be:
>
> counter-argument I'd make is simple: the changes required in IP stacks
> to enable Class-E as valid addressing is minimal, resulting in little
> new code, and thus little risk from untested code. Initially allowing
> blocks from this space as additional RFC1918-style space would provide
> a playground where enterprises, users and vendors could test their
> wares, without risk to the public Internet.
>
> stacks from all of the vendors are largely untested. I don't mean they
> haven't run code coverage, had QA teams and even interoperability
> testing. I mean there is limited experience with wide scale networks,
> high traffic volumes, exposure to denial of service and probing
> attacks. There will be vulnerabilites, just as there is with any code
> that's relatively new.
>
> Leveraging the need of enterprises for additional, sanctioned, private
> IPv4 space for interconnects may result in widescale implementation.
> Or it might not. The point is, it would be relatively simple to find
> out, and would not be overly distracting to the IETF or to efforts to
> migrate to IPv6 .

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Aug 2007 14:29:57 -0700

On Aug 9, 2007, at 12:11 PM, Arnt Gulbrandsen wrote:

> What large private internets are these, really? Are we discussing  
> Google potentially needing more than one /8 for its web servers, or  
> are we discussing providers (DSL, Wimax, 802.11, GSM, 3G or other)  
> giving customers addresses from 240/4 via DHCP or PPP?
>

It will likely take more than a handful of years before this range of  
addresses can be made universally usable as public IP addresses.   
Most unmodified equipment and software treat this range as non- 
routable.  Without some incentive beyond altruism, the requisite  
changes will not occur in a timely manner.  It would be wholly unfair  
to suggest to those late in asking that their assigned public address  
from this range.  However, when employed as a private address, the  
equipment and software that must be upgraded can be ascertained, and  
those that would need to make upgrades are also both motivated and  
able to ensure requisite changes are made.

A large company, Google, access providers and others will easily find  
16 million addresses are easily exceeded.  For example, by employing  
IPv4 to IPv6 proxies, large existing deployments might be readily  
transitioned to IPv6.  When done at a large scale, each event would  
have the potential of freeing up a Class-E worth of unencumbered IPv4  
addresses.  With this in mind, perhaps IPv6 should be assigned in  
blocks of 268,435,456 to any large organization. : )

Yes, there will be considerable pain when using addresses within  
Class-E.  For this to be resolved in a timeframe that has a chance of  
impacting the exhaustion of IPv4 addresses, these problems MUST BE  
resolved within the private address space.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Aug 2007 10:42:53 +1000

> 247.1.76.22 from her cable modem is quite another.

	Cable companies need this amount of address space for
	controlling the CPE boxes.  The customers still get public
	addresses.  That's a minimum of two addresses per customer.

	Large corporations need more than a /8.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Michel Py" <[email-masked]>
Date: Thu, 9 Aug 2007 22:48:00 -0700

Hi Daniel,

[large snip]

Very nice post, as usual. However,

> Daniel Senie wrote:
> Initially allowing blocks from this space as additional
> RFC1918-style space would provide a playground where
> enterprises, users and vendors could test their wares,
> without risk to the public Internet.

I have to disagree with that, and here's why: today: I already get a
10/8 address on my AT&T cell phone. Should 240/4 become an extension of
RFC1918, it won't take operators long to deploy it to customers. In two
years, I don't want to have to fork out another $600 for a cell phone
because mine is not in the upgrade path anymore. Furthermore, I also use
this phone as a wireless modem for a laptop and even if I get a new cell
phone I don't want to have to replace that laptop because the PPP stack
or some other component on it does not understand 240/4.

> Microsoft updates desktops and servers weekly or more often, and

Only for "current" products. I don't think vendors will play ball nicely
on this one. Note that I am not saying they are wrong or bad; I have
shares of some of them; a reasonable amount of built-in obsolescence has
always been there and is good for business. I don't think we should give
vendors extra ammo to push yet another forklift upgrade though; as
discussed above, this proposal has wider ramifications than private
intranets. If it succeeds, it will force many people or organizations to
upgrade to the latest software (which might not be free) or worse have
to buy new hardware capable of running the latest software.

> the changes required in IP stacks to enable Class-E as
> valid addressing is minimal, resulting in little new code,
> and thus little risk from untested code.

The changes might not be limited to software. Remember the good old days
with the classes based on the first bits:
0... Class A
10.. Class B
110. Class C
1110 Class D
1111 Class E
I would not be surprise to find this hard-coded in the silicon of some
hardware-optimized packet processing gear.

In short: I acknowledge the very valid points you make. In the end
though, even if I would have supported this a few years ago, I don't
support it anymore. Too little too late; too small the carrot and a too
big the stick.

Michel.

---

From: <[email-masked]>
Date: Fri, 10 Aug 2007 08:31:12 +0100

> Some widespread IPv4 stacks refuse to handle these addresses, 
> so nobody would ever want to use them on the public IPv4 Internet.

And some widespread IPv4 stacks, refuse to handle IPv6 addresses. I guess that means we should deprecate IPv6? Or should we merely update the software?

In any case, the most worrying aspect of this is the number fo /8's that are proposed to be handed over for private use at a time when we are running short of IPv4 addresses. I would think that two /8s is more than enough.

Assuming that these private users manage to resolve the technical issues of using former class E addresses, and get some vendors to update their software/firmware, then the rest of the /8's should be handed over to the RIRs for general use (with caveats). In much the same way as an applicant for an AS number can now specify that they will accept a 4-byte Asnum, these former class E addresses could be handed out to those who will accept it.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Aug 2007 03:51:47 -0400

[email-masked] wrote:
> And some widespread IPv4 stacks, refuse to handle IPv6 addresses.
>   
it seems likely that more hosts currently support IPv6 than support use
of these IPv4 addresses.  why should we go to more effort to gain a bit
more life out of IPv4 than it takes to transition to IPv6?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Aug 2007 11:35:07 +0200

Keith, all,

The common use case that people discuss is cable.  My impression is that 
CableLabs has done a pretty good job of driving IPv6 adoption in cable 
modems for DOCSIS 3.0.  The authors being from APNIC, I would imagine 
there is a billion person problem (or so) to be solved?

What I'd ask, therefore, is that the authors include in their 
introduction answers to the following questions:

   1. Should the address space be allocated to private networks?  If so,
      please give some examples of uses.
   2. If the space is to be allocated for global reachability, could you
      please provide a current estimate as to how much time is bought?

In addition, while I don't think the coding issues are all that 
substantial, deployment issues could be sizable.  Anyone planning to 
make use of this address space because they have exhausted 10/8 should 
CLEARLY be making plans to go to IPv6.  Anyone expecting to avoid a 
collision through the use of this space should be cautioned.

Also the document should be in the same class as RFC 1918, which is a 
BCP and not a standard.  If you proceed, you might want to consider 
obsoleting 1918 in favor of an abbreviated replacement, as much of the 
text in that document is dated. 

Regards,

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Aug 2007 14:35:00 -0400

One thing I'm pretty sure of is that allocating this space for another
RFC1918-like private network block isn't going to solve the collision
problem.  I could see more utility in letting this be space for "router"
use only, say to allow cable ISPs to assign such addresses to
non-publicly accessible components in their networks.  Such use would
presumably have fewer deployment barriers than use as either ordinary
public or private space. 

I could also see some utility in assigning smaller blocks from this
space to enterprise networks, similar to ULIAs in IPv6.  Such blocks
could be used, for instance, to interconnect between private networks
without address collisions.  But for that kind of use I would assume
that the deployment barriers would be much greater.

Bottom line - I think that any proposal to reassign class E addresses
needs to provide one or more specific use cases.  And for each of those
cases, it should consider deployment cost vs. benefit, and compare that
to the cost vs. benefit of using IPv6.

Keith
> Keith, all,
>
> The common use case that people discuss is cable.  My impression is
> that CableLabs has done a pretty good job of driving IPv6 adoption in
> cable modems for DOCSIS 3.0.  The authors being from APNIC, I would
> imagine there is a billion person problem (or so) to be solved?
>

---

From: <[email-masked]>
Date: Sun, 12 Aug 2007 17:57:31 +0100

> it seems likely that more hosts currently support IPv6 than 
> support use of these IPv4 addresses.  why should we go to 
> more effort to gain a bit more life out of IPv4 than it takes 
> to transition to IPv6?

Because the two are not mutually exclusive. And when companies begin to
suffer significant dollar damages as a result of the IPv4 address
shortage and start slinging unfair lawsuits around, we can get judge to
quickly and CHEAPLY dismiss such lawsuits by demonstrating that we did
not unfairly put roadblocks in the way of solutions that extend the life
of IPv4.

The IETF engineers protocols, not business models or technology choices.
We should make choices available but not try to force people down only
one road. It is not up to the IETF to engineer a transition to IPv6,
merely to make the tools available. Freeing up the former class E space
is an example of making a minor tool available, and it also sends a
strong message that the IETF believes that IPv4's days are numbered,
therefore there is no longer any need to reserve any portion of the IPv4
space for future use.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Aug 2007 14:51:09 -0400

> It is not up to the IETF to engineer a transition to IPv6,
> merely to make the tools available.
nor is it up to the IETF to engineer a (very slightly) longer lifetime
for IPv4.
>  Freeing up the former class E space
some people might interpret that message differently. they might believe
that since we're making a large chunk of new addresses available, it's
okay to keep depending on IPv4.

(seems like we're notoriously bad at getting _any_ message across to the
public, since IETF says little to the media and we don't object when
marketroids from various big name companies claim that we've done things
that we haven't done.)

Keith

---

From: Geoff Huston <[email-masked]>
Date: Mon, 13 Aug 2007 07:24:56 +1000

> presumably have fewer deployment barriers than use as either ordinary

This was a scenario that was envisaged by the authors of the draft as 
being consistent with the intended re-designated use and consistent with 
the caveats noted in the draft.

> to the cost vs. benefit of using IPv6.

The authors were interested in providing a succinct statement of the 
administrative actions required to redefine the use of this currently 
reserved address block.

It would be quite appropriate, as already noted in the draft, to 
generate additional material describing use cases and actions required 
on the part of network admins to enable use of this address prefix in 
various scenarios.

If you, and others who have an interest in this topic, are volunteering 
to write one (or more) such documents about use of this address block 
and/or the caveats relating to such use, then that would be great!

thanks,

      Geoff

---

From: Peter Dambier <[email-masked]>
Date: Mon, 13 Aug 2007 00:16:06 +0200

> DHCP assigned me 255.255.255.255/32.

I remember trying it. I wanted to clandestinely communicate between
linklocal boxes. I could use it with Unifix linux 2.0 and kernel 2.0.48

I did not find any other operating system, not even linux, who could
use it.

I did not find any hardware except nonmanaged switches who could use it.

I tried to "fix" the tcp/ip stack of a more modern linux. Sideffects.
I did not get it working. To many places in the software.

Kind regards
Peter and Karin Dambier

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Aug 2007 08:59:15 +0200

Geoff,

> [cable-modems] was a scenario that was envisaged by the authors of the 
> draft as being consistent with the intended re-designated use and 
> consistent with the caveats noted in the draft.

For a closed system, which is what you are talking about, one could make 
CLNS and TMIP work!!  If you can do that, why not simply use the 
specified standard, IPv6?  Doing otherwise discredits CableLabs and 
probably causes a CM respin.

> administrative actions required to redefine the use of this currently 

That is necessary but NOT sufficient.  There needs to be motivation.  
This was the case in RFCs 1597 and 1918, and it should be so here as 
well.  You are asking for the last allocation of addresses.   Let's have 
the reasoning be sound, please.

> on the part of network admins to enable use of this address prefix in 

That's fine, but without the motivation I would strongly object to this 
document advancing.

Eliot

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 20 Aug 2007 21:48:22 +0200

>         addresses. That's a minimum of two addresses per customer.

One of which can easily be an IPv6 address, so allocating 240/x for this 
would seem to cater to those people who can and will modify their 
devices to accept 240/4, but cannot or will not give them IPv6 ability.

>         Large corporations need more than a /8.

A /48 is that, too...

Arnt

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Aug 2007 09:47:16 +1000

> devices to accept 240/4, but cannot or will not give them IPv6 ability.

	That assumes that they won't work with those addresses today.
	My FreeBSD boxes will happily talk to each other using class
	E addresses.  No everything has had a lobotomy.

	Mark

bsdi# ifconfig tx0 inet 255.255.254.2 netmask 0xffffff00 alias
drugs# ifconfig bge0 inet 255.255.254.1 netmask 0xffffff00 alias
drugs# tcpdump host 255.255.254.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes
09:40:00.364407 IP 255.255.254.2.1565 > 255.255.254.1.ssh: S 3539319153:3539319153(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 11948618 0>
09:40:00.364886 IP 255.255.254.1.ssh > 255.255.254.2.1565: S 2293183390:2293183390(0) ack 3539319154 win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 491719822 11948618>
09:40:00.365495 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 1 win 57920 <nop,nop,timestamp 11948618 491719822>
09:40:00.504633 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 1:40(39) ack 1 win 33304 <nop,nop,timestamp 491719961 11948618>
09:40:00.505719 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1:40(39) ack 40 win 57920 <nop,nop,timestamp 11948632 491719961>
09:40:00.518965 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 40:776(736) ack 40 win 33304 <nop,nop,timestamp 491719976 11948632>
09:40:00.520554 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 40:584(544) ack 776 win 57184 <nop,nop,timestamp 11948634 491719976>
09:40:00.620569 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 584 win 33304 <nop,nop,timestamp 491720078 11948634>
09:40:00.627956 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 584:608(24) ack 776 win 57920 <nop,nop,timestamp 11948644 491720078>
09:40:00.727778 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 608 win 33304 <nop,nop,timestamp 491720183 11948644>
09:40:00.753739 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 776:1056(280) ack 608 win 33304 <nop,nop,timestamp 491720202 11948644>
09:40:00.847195 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 1056 win 57920 <nop,nop,timestamp 11948667 491720202>
09:40:00.866975 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 608:880(272) ack 1056 win 57920 <nop,nop,timestamp 11948668 491720202>
09:40:00.966562 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 880 win 33304 <nop,nop,timestamp 491720422 11948668>
09:40:01.123954 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 1056:2224(1168) ack 880 win 33304 <nop,nop,timestamp 491720579 11948668>
09:40:01.217178 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 2224 win 57920 <nop,nop,timestamp 11948704 491720579>
09:40:03.863875 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 880:896(16) ack 2224 win 57920 <nop,nop,timestamp 11948968 491720579>
09:40:03.967049 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 896 win 33304 <nop,nop,timestamp 491723412 11948968>
09:40:03.967597 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 896:944(48) ack 2224 win 57920 <nop,nop,timestamp 11948979 491723412>
09:40:03.969216 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2224:2272(48) ack 944 win 33304 <nop,nop,timestamp 491723414 11948979>
09:40:03.970430 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 944:1008(64) ack 2272 win 57920 <nop,nop,timestamp 11948979 491723414>
09:40:03.982462 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2272:2336(64) ack 1008 win 33304 <nop,nop,timestamp 491723427 11948979>
09:40:03.984466 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1008:1536(528) ack 2336 win 57920 <nop,nop,timestamp 11948980 491723427>
09:40:04.028809 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2336:2816(480) ack 1536 win 33304 <nop,nop,timestamp 491723473 11948980>
09:40:04.060597 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 1536:2112(576) ack 2816 win 57920 <nop,nop,timestamp 11948988 491723473>
09:40:04.104782 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2816:2848(32) ack 2112 win 33304 <nop,nop,timestamp 491723549 11948988>
09:40:04.106312 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2112:2176(64) ack 2848 win 57920 <nop,nop,timestamp 11948992 491723549>
09:40:04.132479 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2848:2896(48) ack 2176 win 33304 <nop,nop,timestamp 491723577 11948992>
09:40:04.134269 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2176:2560(384) ack 2896 win 57920 <nop,nop,timestamp 11948995 491723577>
09:40:04.152359 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2896:2944(48) ack 2560 win 33304 <nop,nop,timestamp 491723597 11948995>
09:40:04.162486 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 2944:4320(1376) ack 2560 win 33304 <nop,nop,timestamp 491723607 11948995>
09:40:04.164080 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4320 win 56544 <nop,nop,timestamp 11948998 491723597>
09:40:04.925327 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4320:4416(96) ack 2560 win 33304 <nop,nop,timestamp 491724367 11948998>
09:40:04.925396 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4416:4480(64) ack 2560 win 33304 <nop,nop,timestamp 491724367 11948998>
09:40:04.925904 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4480 win 57760 <nop,nop,timestamp 11949074 491724367>
09:40:04.935872 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4480:4544(64) ack 2560 win 33304 <nop,nop,timestamp 491724378 11949074>
09:40:05.027081 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4544 win 57920 <nop,nop,timestamp 11949085 491724378>
09:40:48.766603 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2560:2608(48) ack 4544 win 57920 <nop,nop,timestamp 11953458 491724378>
09:40:48.768701 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4544:4592(48) ack 2608 win 33304 <nop,nop,timestamp 491768033 11953458>
09:40:48.868036 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4592 win 57920 <nop,nop,timestamp 11953469 491768033>
09:40:48.935145 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2608:2656(48) ack 4592 win 57920 <nop,nop,timestamp 11953475 491768033>
09:40:48.936066 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4592:4640(48) ack 2656 win 33304 <nop,nop,timestamp 491768200 11953475>
09:40:49.028134 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4640 win 57920 <nop,nop,timestamp 11953485 491768200>
09:40:49.077229 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2656:2704(48) ack 4640 win 57920 <nop,nop,timestamp 11953489 491768200>
09:40:49.078149 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4640:4688(48) ack 2704 win 33304 <nop,nop,timestamp 491768342 11953489>
09:40:49.177955 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4688 win 57920 <nop,nop,timestamp 11953500 491768342>
09:40:49.193950 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2704:2752(48) ack 4688 win 57920 <nop,nop,timestamp 11953501 491768342>
09:40:49.194933 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4688:4736(48) ack 2752 win 33304 <nop,nop,timestamp 491768459 11953501>
09:40:49.288020 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4736 win 57920 <nop,nop,timestamp 11953511 491768459>
09:40:49.361336 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2752:2800(48) ack 4736 win 57920 <nop,nop,timestamp 11953518 491768459>
09:40:49.367027 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4736:4784(48) ack 2800 win 33304 <nop,nop,timestamp 491768630 11953518>
09:40:49.405998 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4784:4832(48) ack 2800 win 33304 <nop,nop,timestamp 491768669 11953518>
09:40:49.406638 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4832 win 57872 <nop,nop,timestamp 11953522 491768630>
09:40:49.497563 IP 255.255.254.1.ssh > 255.255.254.2.1565: P 4832:4960(128) ack 2800 win 33304 <nop,nop,timestamp 491768760 11953522>
09:40:49.502366 IP 255.255.254.2.1565 > 255.255.254.1.ssh: P 2800:2832(32) ack 4960 win 57920 <nop,nop,timestamp 11953532 491768760>
09:40:49.503259 IP 255.255.254.2.1565 > 255.255.254.1.ssh: F 2832:2832(0) ack 4960 win 57920 <nop,nop,timestamp 11953532 491768760>
09:40:49.503449 IP 255.255.254.1.ssh > 255.255.254.2.1565: . ack 2833 win 33304 <nop,nop,timestamp 491768766 11953532>
09:40:49.507742 IP 255.255.254.1.ssh > 255.255.254.2.1565: F 4960:4960(0) ack 2833 win 33304 <nop,nop,timestamp 491768771 11953532>
09:40:49.508288 IP 255.255.254.2.1565 > 255.255.254.1.ssh: . ack 4961 win 57919 <nop,nop,timestamp 11953533 491768771>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 21 Aug 2007 09:38:38 +0300

> 	E addresses.  No everything has had a lobotomy.

You mean, the same BSD stack that has a specific check for not routing class E 
packets? In all due fairness, I have to admit it does not reject class F+.

-- 
Rémi Denis-Courmont