Re: Packet decode example in draft-ietf-ipdvb-ule-01

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

This appears to resolve the problem described in:

http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00776.html

Gorry

----

Hi Gorry,

Here is the result of the CRC32 recalcualtion for MAC address 
00:01:02:03:04:05

ULE SNDU length  : 63    ULE protocol type : 0x86dd
ULE dest MAC addr: present (D-bit: 0): 00:01:02:03:04:05
ULE CRC32        : 0x4709a744,  verification: Ok (0x4709a744)

0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d   .?........`.....
0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00   :@ ..`0.........
0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00   .. ..`0.........
0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47   .......8.......G
0064: 09 a7 44                                          ..D


Kind regards,
Bernhard


> Someone very kindly pointed a slight "problem" with the worked example
> provided in the  Informative Appendix, ANNEXE B, of the draft ULE
> spec. The current text reads:
>
> " An example of ULE encapsulation carrying an ICMPv6 packet generated
> by ping6.
>
> ULE SNDU Length  :            63 decimal
> D-bit value  :                0 (NPA Present)
> ULE Protocol Type :           0x86dd (IPv6)
> Destination ULE NPA Address:  01:02:03:04:05:06 **** MULTICAST ****
> ULE CRC32 :                   0x784679a5
>
> Source IPv6:                  2001:660:3008:1789::5
> Destination IPv6:             2001:660:3008:1789::6
>
> SNDU contents (including CRC-32):
>
> 0000:  00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
> 0010:  3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00
> 0020:  00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00
> 0030:  00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78
> 0040:  46 79 a5 "
>
>
>Although the CRC-32 is correct, there's a slight irregularity
> in the MAC address cited in the example.
>
> The cited mac address is multicast, whereas the IPV6 address is 
>Unicast...
> Looking at section 4.5 of ULE: " The ****least significant bit****
> of the
>first byte of the address is set to 1 for multicast frames, and the
>remaining bytes specify the link layer multicast address." Note my
>highlighting with "***".
>
>Although this does not invalidate the example - from the point of view 
>of validating the CRC32 calculation - it is not a good example
> of expected >use.
>
>Could someone perhaps please compute the CRC32 again over the same >packet
>using a unicast NPA address instead?
>
> Gorry
>