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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 18 Oct 2004 11:54:24 +0100

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
 >