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

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



Fabian Mauchle wrote:
>> 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?

Since this was done on a proprietary Unix, I'll just try and paraphrase:

1. When processing the HAO, you need to do a binding cache lookup to validate
it.  You can "remember" whether you found an entry, and whether you swapped the
address.  You need to continue to process it...

2. When processing the MH, you can consult the saved saved information from step
#1 - did I see a HAO?

You know, I might have just not read the proposal correctly.  I think the:

 "If the Next Header value of the Destination Option is one of the following:
 {50 (ESP), 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
 normally. Else, the packet MUST be dropped..."

text is fine.  I don't think any other next header types would be valid.

Sorry about any confusion.

-Brian