Subject: Re: [Int-area] draft-fuller-240space-00.txt

From: Joe Touch <[email-masked]>
Date: Sun, 30 Sep 2007 23:37:17 -0700

255.255.255.255 is used as the destination IP address for ARP, DHCP, and
a number of other protocols, i.e., local broadcast.

The endpoint of that range ought to be 255.255.255.254, no?

Joe

Danny McPherson wrote:
> 
> On Sep 22, 2007, at 9:10 AM, Iljitsch van Beijnum wrote:
> 
>> On 17-sep-2007, at 12:11, Eliot Lear wrote:
>>
>>> Comments?
>>
>>    At the present time, most IP implementation consider any IP address
>>    in the range 240.0.0.0 through 255.255.255.255 to be invalid as the
>>    source or destination of a datagram.
>>
>> This is untrue. _Most_ implementations have no problem with it.
> 
> Iljitsch,
> I'd be quite interested in any empirical evidence you might have
> in support of this statement.  Pointers welcome.
> 
> Thanks!
> 
> -danny
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 00:56:37 -0600

> The endpoint of that range ought to be 255.255.255.254, no?

Righto, "limited broadcast", and only to be used as destination.  I
don't see any others in RFC 1700, RFC 3330 or the like (nor did I
expect to).

-danny

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Oct 2007 09:26:12 +0200

> The endpoint of that range ought to be 255.255.255.254, no?

Yes, but I'm not sure what we change in practice.

Eliot

---



Frootocols  
through more or less transparently, so any device connected to the  
modem, such as a PC or a home gateway/router without the modem  
function built in, will have to engage in authentication directly. In  
the case of the integrated home gateway, the authentication  
credentials would be configured on the gateway and client PCs  
wouldn't have to run the authentication protcol.

If PCs are expected to run the authentication protocol, I have two  
issues (in addition to the ones already mentioned, of course). The  
first is that, assuming the same options are defined for IPv6, I  
would oppose a de-facto requirement that all IPv6 hosts run DHCPv6.  
(Or DHCP for IPv4, for that matter.) For IPv4 hosts, the requirement  
to run DHCP doesn't seem excessive, considering current practice. The  
other issue is how the authentication is started. If client is  
expected to initiate authentication in the first message, this means  
it's not possible to have a client that can seamlessly connect to  
multiple networks that require authentication because the client  
wouldn't know which credentials to use at any given time. Also, being  
easily prompted to send credentials would be a security isssue: an  
attacker could initiate frequent DHCP exchanges to harvast hashed  
credentials. (Experience with WEP shows that this can be detrimental  
under certain circumstances.) So a mechanism where the server  
authenticates itself to the client would be a lot better.

Also, one of the drafts mentions MD5, which is pretty much dead in  
the water with a huge hole in the hull right now, it's only a matter  
of time until it officially sinks.

Further, I'd like to see a more general mechanism. Another situation  
where users need to provide credentials that can benefit from better  
standards are wifi hotspots. This situation is largely similar to the  
DSL situation with the exception that there is often no direct  
relationship with the operator of the hotspot and the user, so the  
user must either select a roaming partner and provide credentials  
appropriate for that roaming partner, or use some other interactive  
method to gain temporary access (scratch cards, credit card  
transactions).

This suggests that a mechanism where unauthenticated users are given  
temporary access to a walled garden and then full access at some  
later point would be more appropriate than a simple success/fail  
authentication method.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Oct 2007 21:26:15 +0200

> in support of this statement.  Pointers welcome.

I've tested this with various BSD-derived implementations over the  
years, and they don't remember any problems.

But (on my Mac):

$ sudo ifconfig lo0 alias 240.240.240.240/32
$ ping -c 3 240.240.240.240
PING 240.240.240.240 (240.240.240.240): 56 data bytes
^C
--- 240.240.240.240 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
         inet 127.0.0.1 netmask 0xff000000
         inet 240.240.240.240 netmask 0xffffffff
$ sudo ifconfig lo0 alias 1.240.240.240/32
$ ping -c 3 1.240.240.240
PING 1.240.240.240 (1.240.240.240): 56 data bytes
64 bytes from 1.240.240.240: icmp_seq=0 ttl=64 time=0.047 ms

So apparently you can configure a class E address but it doesn't work  
even though a class A address under the same circumstances does work.

m: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [Int-area] draft-fuller-240space-00.txt
Date: Fri, 5 Oct 2007 21:26:15 +0200
To: Danny McPherson <[email-masked]>
Cc: Internet Area <[email-masked]>

> in support of this statement.  Pointers welcome.

I've tested this with various BSD-derived implementations over the  
years, and they don't remember any problems.

But (on my Mac):

$ sudo ifconfig lo0 alias 240.240.240.240/32
$ ping -c 3 240.240.240.240
PING 240.240.240.240 (240.240.240.240): 56 data bytes
^C
--- 240.240.240.240 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
         inet 127.0.0.1 netmask 0xff000000
         inet 240.240.240.240 netmask 0xffffffff
$ sudo ifconfig lo0 alias 1.240.240.240/32
$ ping -c 3 1.240.240.240
PING 1.240.240.240 (1.240.240.240): 56 data bytes
64 bytes from 1.240.240.240: icmp_seq=0 ttl=64 time=0.047 ms

So apparently you can configure a class E address but it doesn't work  
even though a class A address under the same circumstances does work.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 06 Oct 2007 13:33:41 +0200

Vince has done a fair amount of testing of general purpose OSes, and has
diffs for LINUX.  Geoff Huston has also done some work in this area.  We
do not know how any number of imbeded stacks behave.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 6 Oct 2007 16:12:40 +0200

> years, and they don't remember any problems.

FreeBSD:

# ifconfig em1 241.241.241.241/24
# telnet 241.241.241.241 80
Trying 241.241.241.241...
Connected to 241.241.241.241.
Escape character is '^]'.

Cisco:

#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
(config)#in lo242
hpromatem(config-if)#ip addr 242.242.242.242 255.255.255.255
Not a valid host address - 242.242.242.242

But:

#traceroute 241.241.241.241

Type escape sequence to abort.
Tracing the route to 241.241.241.241