lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] ipv6 processing


From: Enrico Lehmann
Subject: [lwip-devel] ipv6 processing
Date: Thu, 26 Apr 2012 21:35:23 +0200

Hello all, Ivan

First thanks Ivan for that great work on the IPv6 implementation (and Simon for 
doing some lwIP 'integration' parts t ;-) ). I'm using lwIP in dual-stack and 
IPv6-only stack (some minor modifications) mode. Only using UDP and it works 
great.

Let me ask you, especially Ivan, something about your ip6_input() 
implementation. 
If any message is received, you check for proper IPv6 header and than check if 
destination address is a kind of multicast or unicast address. If it is a 
unicast address, you check all available network interfaces (netif's) if the 
destination address is configured as one of it's addresses. But is this not a 
kind of gateway behaviour?

On a 'normal' host wouldn't you just check your input netif if destination 
address matches? For example you have two netif's and a data packet is targeted 
to the second netif, which is not the input netif, the packet is processed by 
e.g. the UDP input function but with the wrong netif. Shouldn't the incoming 
netif not be replaced by the previous selected netif (the netif where the 
destination address match occurs)?

I see two possibilities:
1.) Keep that kind of gateway behaviour (which I like, since I need that one), 
but then the input netif 'inp' must be replaced by the matching netif 'netif'.
2.) Only match the destination address with configured addresses of the input 
netif 'inp'.

Maybe I missed something and it behaves quite different, but then, perhaps, you 
can enlighten me :-)

--------------

A second thing correspond to the Solicited-Node-Multicast Address. Shouldn't 
the last 24 Bits matched to the netif's configured addresses? This would 
immediately stop further processing and therefore save processing time and is 
much faster, since it would omit icmp6_input() and nd6_input() processing.

--------------

The third question is about the Echo Request/Response processing in 
icmp6_input(). If an Echo Request is detected, the IPv6 source address of the 
Echo Response message is determined by calling ip6_select_source_address(). 
Shouldn't this IPv6 source address not the same as the IPv6 destination address 
of the Echo Request message? A quote from RFC 4443 [chapter 4.2]:

"The source address of an Echo Reply sent in response to a unicast Echo Request 
message MUST be the same as the destination address of that Echo Request 
message."

As I understand this would omit the ip6_select_source_address() and simplifies 
it to just use the ip6_current_dest_addr() address (previous make sure this is 
not a multicast address).

--------------

My last question is about a (Border/Edge)-Router implementation. If I remember 
right, last year you wrote you are working on such a IPv6 addition. Have you 
made any process there. Any input would be great.

--------------

Thanks in advance,
Enrico


-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]