Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option"

[Fabian Mauchle <f1mauchl at hsr.ch>]

-----Ursprüngliche Nachricht-----
Von: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] Im Auftrag von
Brian Haley
Gesendet: Mittwoch, 27. Mai 2009 05:15
An: Charles E. Perkins
Cc: mext
Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
errors"], part 1 of 3: "Receiving Home Address Destination Option"

Hi Charlie,

Charles E. Perkins wrote:
> 
> Hello folks,
> 
> Last month, issue #18 showed up without any fanfare on the
> issues tracker list:
>    http://trac.tools.ietf.org/wg/mext/trac/ticket/18
> I'd like to initiate discussion on the points raised as part
> of issue #18.  There are three main points, which can be
> discussed separately.  In this note, I transcribe the
> discussion about the first of the three points.
> 
> =============================================
> 
> Receiving Home Address Destination Option
> 
> In Section 9.3.1. Receiving Packets with Home Address Option:
> "Packets containing a Home Address option MUST be dropped if
> there is no corresponding Binding Cache entry. (...) These
> tests MUST NOT be done for packets that contain a Home Address
> option and a Binding Update."
> 
> The second part of this statement (packets that contain a Home
> Address option and a Binding Update) requires looking ahead in
> the packet for a Mobility Header with a respective type. This
> action is stricly forbidden by IPv6 (RFC 2460, Section 4):
> "The contents and semantics of each extension header determine
> whether or not to proceed to the next header. Therefore, extension
> headers must be processed strictly in the order they appear in
> the packet; a receiver must not, for example, scan through a
> packet looking for a particular kind of extension header and
> process that header prior to processing all preceding ones."

The assumption about looking ahead in the packet is not correct, I've
implemented this without doing it :)  Since a HAO isn't mandatory in all
BU's
(deletion for example), that processing code just needs to know if one was
seen
previously - if not the packet could be silently dropped.

-Brian
---------------------------------

Would be interesting how this looks like. Maybe you could post some (pseudo)
code which shows the processing and drop decision of the Home Address
Option?

Fabian