>	I still do not understand your goal... anyway,

sorry, i didn't really go into that yet.  i wanted to create a "null"
network interface, similar to that which one might find on a cisco.
useful for blackhole routing, ipfiltering (yes, really!), etc.

>>(1) on one tty, i do "ping 127.0.0.2" and on another, i do "tcpdump
>>-nilo0".  what i see is:
>>
>>   # tcpdump -nilo0
>>   tcpdump: listening on lo0
>>   23:11:02.868037 127.0.0.1 > 127.0.0.2: icmp: echo request
>>   23:11:02.868159 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
>>   23:11:03.892777 127.0.0.1 > 127.0.0.2: icmp: echo request
>>   23:11:03.892874 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
>>   ...
>>yet the ping program doesn't recognize these responses.
>
>	echo reply with ttl 1 is generated by ping, to flush route cache
>	in ip_output.

echo reply with ttl 1 seems to be generated by the kernel for the
loopback interface so that it won't get forwarded off the system.  i
can understand ping not picking them up (the source address is not
what it expects) but what i can't understand is why the kernel
generates them at all: there's no 127.0.0.2 address anywhere on the
system, and the source address is wrong, as if the response simply was
simply mechanically generated.  hmm...i imagine that's actually it.

yep.  i think that's it.  if i "route add 1.2.3.4 127.1" and then
"ping 1.2.3.4" i see exactly the same responses, 127.1 -> 127.1, even
though 1.2.3.4 isn't an address on the system.  ihmo, replies should
not get generated so automatically.

>>(2) i start with "ifconfig lo1 126.0.0.1" (yes, i have more than one).
>>then i ping 126.0.0.2.  here, i get different packet patterns.
>>   # tcpdump -nilo1
>>   tcpdump: listening on lo1
>>   23:12:34.134754 126.0.0.1 > 126.0.0.2: icmp: echo request
>>   23:12:35.134750 126.0.0.1 > 126.0.0.2: icmp: echo request
>>   ...
>
>	try looking at lo0 as well.   you will see the following packets.

yep.  found that five minutes later.  :)

>>>   23:11:03.892874 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
>	again, this packet is generated by ping.

i still disagree.  ping doesn't make answers...only questions.

>>(3) i see that as soon as i ifconfig lo0, ipv6 automatically assigns it
>>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>>   inet6 ::1 prefixlen 128
>>and then lo1 gets
>>   inet6 fe80::1%lo1 prefixlen 64 scopeid 0x2
>>   inet6 ::1 prefixlen 128
>>is this a problem?  "route get -inet6 ::1" reports lo0, but i expect
>>that's only because it's first in the "list".
>
>	i don't think this is a problem, however, i'm not sure what is the
>	specwise correct behavior against lo1.

i'm not sure why anyone would have more than one loopback interface,
but i wanted to play a little.  i figured i had anough rope to built a
bridge...or something like that.

you ought to know this...does the ::1 address get added only because
the interface is marked IFF_LOOPBACK or is there some other reason?

>>(4) not really a problem...more of a question.  what theoretical
>>effect would setting IFF_BROADCAST on the loopback interfaces have?
>
>	if we remove special handling for 127.0.0.1, we may want to
>	configure 127.0.0.1 with below:
>	# ifconfig 127.0.0.1 netmask 0xffffffff
>	rather than the default
>	# ifconfig 127.0.0.1 netmask 0xff000000	(netmask implicitly specified)

i still feel that the default netmask is fine...i think i'm just
questioning some of the "special handling" that interfaces marked
IFF_LOOPBACK get in the kernel.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."