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 <***@oracle.com> wrote:
>
>
>
>> On 07/18/2017 09:13 AM, Bernie Volz (volz) wrote:
>> 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)
> Correct. The response is legal but is the behavior of the V6 node to accept and process a V4 broadcast packet correct ?
>
> Shoaib
>>
>>> On Jul 18, 2017, at 5:58 PM, Rao Shoaib <***@oracle.com> wrote:
>>>
>>>
>>>
>>> On 07/18/2017 12:10 AM, Bernie Volz (volz) wrote:
>>>>>> That means that DHCPv4 servers sniff packets off of the wire and do
>>>> their own IPv4/UDP processing.
>>>>
>>>> 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)
>>> 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
>>>>>> On Jul 18, 2017, at 3:15 AM, Mark Smith <***@gmail.com> wrote:
>>>>>>
>>>>>> On 18 July 2017 at 05:41, Erik Kline <***@google.com> wrote:
>>>>>> 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.
>>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>>> On 18 July 2017 at 04:33, Rao Shoaib <***@oracle.com> wrote:
>>>>>>> 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.
>>>>> 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.
>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Shoaib
>>>>>>>
>>>>>>> Please include me in the reply as I am not subscribed to the list.
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> ***@ietf.org
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ***@ietf.org
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ***@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>