Subject: What is the correct behavior

From: Rao Shoaib <[email-masked]>
Date: Mon, 17 Jul 2017 12:33:34 -0700

I am looking at a system which is configured for IPv6 only but sits in a 
network that serves both IPv4 and IPv6. When an IPv4 packet with a 
destination  broadcast address is sent out (in this case DHCP) the 
system accepts it and since it does not have any route to the sender it 
prints the Linux Martian packet message.

Sure, we can turn off the Martian message and maybe the system should be 
in an IPv6 only network but the question that is being asked is that is 
it correct for the system to accept and process an IPv4 broadcast packet 
in the first place ?  Can the experts help me out here.

Thanks,

Shoaib

Please include me in the reply as I am not subscribed to the list.

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Jul 2017 04:41:52 +0900

I'm not sure there is any standards behaviour applicable here.

The device is likely receiving many other non-0x86dd frame types as
well (LLDP, 802.1q, ...).  If you don't want them, probably best to
just filter them.

On 18 July 2017 at 04:33, Rao Shoaib <[email-masked]> wrote:
> destination  broadcast address is sent out (in this case DHCP) the system
> accepts it and since it does not have any route to the sender it prints the
> Linux Martian packet message.
>
> Sure, we can turn off the Martian message and maybe the system should be in
> an IPv6 only network but the question that is being asked is that is it
> correct for the system to accept and process an IPv4 broadcast packet in the
> first place ?  Can the experts help me out here.
>
> Thanks,
>
> Shoaib
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 17 Jul 2017 12:48:28 -0700

> well (LLDP, 802.1q, ...).  If you don't want them, probably best to
Sure, filtering is an option but don't you think handling of ipv4 
broadcast needs to be specified by IETF so all implementations do that 
the same thing. I want to submit a patch for the Linux kernel to not 
process the packet, but since the standard does not say anything it will 
most likely be not accepted.

Rao.

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jul 2017 11:15:03 +1000

> well (LLDP, 802.1q, ...).  If you don't want them, probably best to

A related issue might be that DHCPv4 specifically suffers from a
chicken-and-egg problem, meaning that it is processing IPv4/UDP
packets before IP has been configured. Consequently the DHCPv4 servers
sniff packets off of the wire and do their own IPv4/UDP processing.

So even though your interface to the network isn't "IPv4 enabled" by
having an IPv4 address, if a DHCPv4 server is listening on that
interface then IPv4 packets such as broadcasts will be making it into
the DHCPv4 server process and then the DHCPv4 server process might be
passing them onto and into the IPv4 protocol implementation in the
kernel, causing the martian error.

>> first place ?  Can the experts help me out here.

You may be encountering the DHCPv4 chicken-and-egg problem, meaning
that DHCP has to process IPv4/UDP packets before IP has been
configured by DHCP.

That means that DHCPv4 servers sniff packets off of the wire and do
their own IPv4/UDP processing.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Jul 2017 07:10:44 +0000

That's typically not necessary for DHCP servers to do that. The one I work on certainly doesn't do that as using the standard Linux socket interface works just fine.

- Bernie (from iPhone)

> On Jul 18, 2017, at 3:15 AM, Mark Smith <[email-masked]> wrote:
>

---

From: Rao Shoaib <[email-masked]>
Date: Tue, 18 Jul 2017 08:58:25 -0700

> That's typically not necessary for DHCP servers to do that. The one I work on certainly doesn't do that as using the standard Linux socket interface works just fine.
In this case the host is a client that is getting the DHCP packet 
destined for another host. If the system does not have V4 configured 
than should it not be required to use DHCP v6 ?

Shoaib

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Jul 2017 16:13:51 +0000

This can happen if a client on the LAN requests a broadcast response (or the relay or server broadcasts it for other reasons). See the broadcast flag in RFC2131.

- Bernie (from iPhone)

> On Jul 18, 2017, at 5:58 PM, Rao Shoaib <[email-masked]> wrote:
> 
> 
> 
> In this case the host is a client that is getting the DHCP packet destined for another host. If the system does not have V4 configured than should it not be required to use DHCP v6 ?
> 
> Shoaib
>>

---

From: Rao Shoaib <[email-masked]>
Date: Tue, 18 Jul 2017 10:59:39 -0700

> This can happen if a client on the LAN requests a broadcast response (or the relay or server broadcasts it for other reasons). See the broadcast flag in RFC2131.
Correct. The response is legal but is the behavior of the V6 node to 
accept and process a V4 broadcast packet correct ?

Shoaib

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Jul 2017 21:17:05 +0000

I don't see why a v6 client or server would be processing a v4 packet. DHCPv6 uses a different port.

Perhaps the code supports both and that is why it is processing it. 

- Bernie (from iPhone)

> On Jul 18, 2017, at 7:59 PM, Rao Shoaib <[email-masked]> wrote:
> 
> 
> 
> Correct. The response is legal but is the behavior of the V6 node to accept and process a V4 broadcast packet correct ?
> 
> Shoaib
>>