[Top][All Lists]
[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
- [lwip-devel] ipv6 processing,
Enrico Lehmann <=