Wireshark-bugs: [Wireshark-bugs] [Bug 10673] IPv6 RPL Routing Header calculates Full Address fie

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 24 Oct 2015 11:27:53 +0000

Comment # 8 on bug 10673 from 
(In reply to boaz.brickner from comment #7)
> Hi João,
> Sorry for the late reply.
> 
> I'm opening this to get more information, not saying there's actually a bug.
> 
> A few questions:
> 
> 1. Why is it ok to assume there can't be more than one Routing Header? In
> RFC 3542 I've seen a sentence saying "When multiple Routing headers are
> received...".

Maybe my wording wasn't very clear there. There definitely can be more than one
routing header, although RFC 2460 says there "should" be only one.

   Each extension header should occur at most once, except for the
   Destination Options header which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

When I said RFC 6554 assumes there won't be more than one routing header per
packet, I meant for clarity and ease of exposition in the RFC, taking into
account the most common case. I did not mean to suggest there was any normative
restrictions to having a single routing header per IPv6 packet. I'm not aware
of any such restriction for IPv6 off the top of my head.

> 2. In RFC 6554, it says "IPv6 Destination Address field". This seems quite
> specific to the IPv6 header destination address, and not the calculated IPv6
> final destination value.

... final destination value *for all the previous routing headers*. That's the
"IPv6 Destination Address" when the RPL module looks at the IPv6 packet. So, in
other words, they're the same. I think that you need to keep in mind that the
RPL routing header is only processed after the Mobile IP routing header by the
IP stack, and that the MIPv6 routing header changes the IPv6 destination
address.

Anyway that's my understanding. Hope that helps.

> 
> I'm not saying your analysis is wrong, I'm just trying to understand why do
> we need to take the "final destination of whatever weird combination of
> routing headers precedes it" in this case, according to the RFCs.
> I want to be convinced of that before I change the behavior of Pcap.Net to
> match that.
> 
> Thanks,
> Boaz.

You are receiving this mail because:
  • You are watching all bug changes.